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Preface 



For the fourth time this year, in cooperation with Springer- Verlag, the Euro- 
pean Conference on Object-Oriented Programming (ECOOP) conference series 
is glad to offer the object-oriented research community the ECOOP 2000 Work- 
shop Reader, a compendium of workshop reports, panel transcripts and poster 
abstracts pertaining to the ECOOP 2000 conference, held in Cannes and Sophia 
Antipolis from 12 to 16 June. 



Workshop Reports 

This year, ECOOP 2000 hosted 22 high-quality workshops covering a large spec- 
trum of hot research topics. These workshops were chosen from 38 proposals by 
a workshop selection committee, following a tight peer review process. Our first 
thanks go to the members of this selection committee who worked hard during 
late 1999 and early 2000 to select the best proposals, propose potential merges, 
and help those selected to enhance their final material. Given the quality of the 
proposals, the selection was tough; we therefore owe a special thanks to all of the 
submitters for their efforts, which helped in making the ECOOP 2000 workshop 
program a success. 

Together, the 22 workshops held in conjunction with the conference attracted 
more than 500 position papers, and so gathered more that 500 participants on 
the Ecole Superieure en Sciences Informatiques/Institut National de Recherche 
en Informatique et en Automatique (ESSI/INRIA) campus of Sophia Antipolis 
on 12-13 June 2000. You will find in this volume the reports from the workshop 
organizers of 18 of these. 

Following the efforts of our preceding workshop chairs, we strived for high- 
quality value-adding and open-ended workshop reports. The result, as you can 
judge in the following pages, is a tremendous thought-provoking snapshot of 
the current research in object-orientation, full of pointers for further exploration 
of the covered topics. We have to thank in a very special way our workshop 
organizers who, despite the additional burden put on their shoulders, did a great 
job. 

Each workshop report that you will find in this volume provides you with 
a starting point of choice to understand and explore the currently debated is- 
sues in each area of concern. To achieve this, after summarizing the workshop 
goals, each report offers a critical summary of the contributions as well as tran- 
scripts of the actual workshop debates. It also provides you with the complete 
list of participants, affiliations and contact information, as well as the list of the 
contributed position papers^. Most of them also include a list of relevant pub- 

^ The reports do not include excerpts or abstracts of the more than 500 positions 
papers contributed. It would have been impossible to give a fair amount of space to 
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lications and websites where you will find more information about the covered 
topics. 

Most of the reports have a length of around 15 pages, but there was one 
request for a much larger page allocation: the Workshop on Aspects and Dimen- 
sion of Concerns. We responded positively to that request because their report 
is not only a workshop report, but is a fairly complete survey of this topic, more 
than five years after Kiczales’ seminal work in the area. Also, this workshop 
attracted, by a large degree, the highest number of participants. 

Finally, as editors, we have decided to harmonize the titles of the reports to 
mention only the topics of the workshops. This harmonization avoids repeated 
references to ECOOP 2000 in the titles, which was originally done in several dif- 
ferent ways by the authors. Basically, each workshop report should be referenced 
as “Report from the ECOOP 2000 Workshop on ...”, to which you merely add 
the workshop title. 

Panel Transcripts 

Two panels were held during ECOOP 2000, one of which has its transcript in- 
cluded in this volume. The panel on “Mobile Code, Internet Security, and e- 
Commerce”, moderated by Refik Molva (Eurecom, France), gathered five par- 
ticipants: Ciaran Bryce (University of Geneva), Elena Ferrari (University of Mi- 
lan), Cedric Fournet (Microsoft Labs, Cambridge), Doug Lea (SUNY Oswego), 
and Peter Lee (CMU). 

This topic was chosen both because it is an important and currently debated 
problem, but also because of the strong involvement of the Sophia Antipolis 
high-tech park (sometimes called the “telecom valley”) in telecommunications 
and computer science. The panel was held on the last day of the conference, 
following several other mobility- and security-related conference events, such as: 

— the workshop on Mobile Object Systems (see their report on p. 241); 

— a tutorial on “Object-Oriented Considerations in Designing the Java 2 Se- 
curity Architecture”; and 

~ an invited talk on “Developing Security Systems in the Real World”, also 
given by Li Gong (Sun Microsystems); and, finally, 

— another invited talk on “Using Objects for Next Generation Communication 
Services” given by Munir Cochinwala (Telcordia Technologies) which also 
included security and mobility aspects. 



Poster Abstracts 

The ECOOP 2000 poster session gathered 15 poster presentations out of 18 sub- 
missions. It was held within the exhibition hall where the posters were accessible 

each of them. Instead, several reports include pointers to websites where the position 
papers can be found. 
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during the whole conference. ECOOP posters provide a medium to describe work 
in progress and to elicit feedback from the 00 community. As such, it is often 
used by young researchers to test new ideas for promising research avenues. 
Posters of one ECOOP are often the starting points for papers at the following 
conferences. Thus, some of the abstracts collected here may prefigure some of the 
future hot research topics. Although they cover a relatively wide spectrum, the 
topics of choice for this year’s posters were evolution and adaptability. Aspects, 
roles, persistence, cooperation and composition were also essential elements of 
the session. 



October 2000 Jacques Malenfant 

Sabine Moisan 
Ana Moreira 
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Abstract Previous workshops on reflection both in ECOOP and in OOPSLA 
have pointed out the growing interest and importance of Reflection and Metalevel 
Architectures in the fields of programming languages and systems (ECOOP’98, 
OOPSLA’98), software engineering (OOPSLA’99) and middleware (Middleware 
2000 ). 

Eollowing these workshops but also the conference Reflection’ 99 held in Saint- 
Malo (France), this workshop has provided an opportunity for researchers with 
a broad range of interests in meta-level architectures and reflective techniques to 
discuss recent developments in this field. It has also provided a good test-bed for 
preparing them to submit their works to Reflection’Ol. 

The workshop main goal is to encourage people to present works in progress. 
These works could cover all the spectrum from theory to practice. To ensure 
creativity, originality, and audience interests, participants have been selected by 
the workshop organizers on the basis of 5-page position paper. We hope that the 
workshop will help them to mature their idea and improve the quality of their 
future publications based on the presented work. 



Workshop Objectives 

Over the last 15 years. Reflection and Metalevel Architectures have attracted the atten- 
tion of researchers throughout computer science. 

Reflective and meta-level techniques have now matured to the point where they are 
being used to address real-world problems in such areas as: programming languages, 
operating systems, databases, software engineering, distributed computing, middleware 
expert systems and web-computing. For example, reflective features such as separation 
of concerns and flexibility provide a “plug and play” environment for enabling the run- 
time modification of policies in middleware. 

The main goal of this workshop is to address the issues arising in the definition and 
construction of reflective systems and to demonstrate their practical applications. To 
enable lively and productive discussions, participants had to present a brief introduction 
to their work in this area. 
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Objective of this workshop is to favor a working dialogue between participants in 
order to improve their current work and to prepare the third international conference on 
Reflection and Metalevel Architectures (Reflection’Ol). 



Workshop Topics and Structure 

Presentations have been accepted on topics including, but not limited to, the following: 

- Reflective features of ohject-oriented languages (C++, Java, Smalltalk, and so on) 

- Practical experience with reflective programming 

- Reflective system architecture (operating systems, middleware, embedded, mobile 
computing, and so on) 

- Reflective implementation of non-functional requirements (real-time, fault-tolerance 
and security issues) 

- Implementation techniques (open compilers, specializers, analysis, and so on) 

- Reflective software engineering (adaptive software components, MOP, AOP, meta- 
models, and so on) 

The workshop has been organized in four sessions. Each session is characterized by 
a dominant topic which describes the presented papers and the related discussions. The 
four dominant topics are: software engineering, meta-level architecture, middleware, 
and program translation. During each session, half time has been devoted to papers 
presentation, and the rest of the time has been devoted to debate about the on-going 
works in the area, about the role of reflection and its trend relatively to the dominant 
topic of the session. The discussion related to each session has been brilliantly lead 
respectively by Gilad Bracha, Pierre Cointe, Takuo Watanabe, and Satoshi Matsuoka. 

The workshop has been very lively, the debates very stimulating, and the high num- 
ber of registered attendee from several countries (see appendixEl) testifies the growing 
interest in reflection and its potentiality and applications. 



Important References 

To an occasional reader who would like to learn more about reflection and related topics, 
we suggest to read the basic papers on the topic: 

- Brian C. Smith. Reflection and Semantics in Lisp. In Proceedings of ACM Sympo- 
sium on Principles of Programming Languages, pages 23-35, 1984. 

- Pattie Maes. Concepts and Experiments in Computational Reflection. In Proceed- 
ings of the 2nd OOPSLA’87, pages 147-156, October 1987. 

and to consult the following books on the topic: 

- Gregor Kiczales, Jim des Rivieres, and Daniel G. Bobrow. The Art of the Metaob- 
ject Protocol. MIT Press, Cambridge, Massachusetts, 1991. 

- Chris Zimmerman, editor. Advances in Object-Oriented Metalevel Architectures 
and Reflection. CRC Press, Inc., Boca Raton, Florida 33431, 1996. 
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- Pierre Cointe, editor. Proceedings of the 2nd International Conference on Meta- 
Level Architectures and Reflection (Reflection’ 99), Springer Verlag - LNCS 1616, 
Saint-Malo, France, July 1999. 

- Walter Cazzola, Robert J. Stroud, and Francesco Tisato, editors. Reflection and 
Software Engineering, LNCS 1826. Springer, Fleidelberg, Germany, June 2000. 

Besides, to keep up to date with the reflection area evolution we can consult the pro- 
ceedings of the late workshops and conferences on reflection, and the following pages: 

- Reflection links: 

http : / / computer . org/ channels/ds/middleware/RMref lection . htm, 
and 

- Reflective midddleware links: 

http ; / / computer . org/ channels/ ds/middleware/RM . htm 

which collect a lot of useful links related to reflection (in a general sense), and applied 
to middlewares. 

Beyond to present statistical information about the workshop and general informa- 
tion about the current state of art of the research in the reflection area, this report gathers 
together the opinions of the session chairs relatively to the session they lead, and the 
opinions of the workshop organizers about the overall workshop and the results the 
workshop achieved with respect to the initial objectives. 

1 Workshop Overview: Session by Session 

Session on Software Engineering: 

Summary by Gilad Bracha (Session Chair, Sun Java Software) 

Two talks were given in this session: 

Q Using Reflective Features to Support Mobile Users. Vania Marangozova and Fabi- 
enne Boyer (INRIA, France) 

Vania Marangozova gave the talk. 

0 Towards a Reflective Component Based Middleware Architecture. Nikos Parla- 
vantzas, Geoff Coulson, Mike Clarke, and Gordon Blair (Lancaster University, 
United Kingdom) 

Nikos Parlavantzas gave the talk. 

Q described a application that used an extension of Java with the ability to dynam- 
ically adapt objects behavior. Both Jacques Malenfant and I commented that the paper 
did not (but absolutely should) refer to the concept of delegation, which was clearly 
related to the language extension used. 



4 



Walter Cazzola, Shigeru Chiba, and Thomas Ledoux 



Described a middleware architecture based on OpenCOM, a COM extension. 
The middleware so constructed supports reflection and is itself constructed out of com- 
ponents. 



In the discussion, I (Gilad Bracha) played devil’s advocate. I challenged everyone to 
argue for the pragmatic value of the more advanced uses of reflection that researchers 
have proposed in recent years. Is there, for example, a “killer application” for their 
approach. After all, the basic reflective techniques of querying an object for its class 
and methods, fields etcetera have been used for at least 20 years. So has the capacity 
to reflectively modify a program by changing methods, object schemas etcetera. These 
capabilities are showing up in industry now and have clear value. Are more exotic uses 
simply past the point of diminishing returns? 

For example, how valuable is the ability to trap calls to specific objects (in languages 
that do not naturally support this)? And if this is valuable, is reflection the correct way 
to support it? In languages that support delegation one can easily do this dynamically. 

Various participants responded with comments on the value of malleability in gen- 
eral. In particular, Fabio Costa argued that the more “exotic uses” are those related to 
behavioural reflection, i.e., the ability to do reflection (inspection and intercession) into 
the underlying mechanisms used to carry out method calls, message handling, and so 
on. Such mechanisms normally refer to the non-functional properties associated with 
the method execution. By allowing the manipulation of non-functional properties us- 
ing a reflective meta-interface, we achieve a degree of separation of concerns which is 
highly desirable. 

There are, however, alternative ways of achieving this same goal, such as AOP, but 
reflection gives the ability to handle these issues in a dynamic way (especially, if they 
are not known a priori). 

My response was that while this is true, we must be able to show massive (order-of- 
magnitude) benefits in order to displace an established (or well marketed) technology. 
We have repeatedly seen that being twice as good is not nearly good enough. If leading 
edge work requires a significantly different model than current practice, it can only have 
an impact if benefits are overwhelmingly compelling. 



The discussion of this matter was interleaved with a related point, which I also 
posited rather provocatively. Are people stretching the definition of reflection too broad- 
ly? 

Some of the examples given in the papers seemed to be just good object-oriented 
engineering, and had little to do with reflection as 1 saw it. For example, is delega- 
tion inherently a reflective mechanism? 1 would say no, but it is not clear if there is 
universal agreement. After all EJ is a paper on using reflection that presents a Java lan- 
guage extension closely related to delegation. If so, we can take this further and ask: 
are higher-order functions inherently reflective? If they are, so is any object oriented 
program. 
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As another simple example, the fact that a machine can report on its status is indeed 
reflective, but is nothing new. In particular, while the machine is reflective, the program 
that reports on, say, the status of the hardware is not reflective at all. 

Many in the audience felt that my view of reflection was too narrow, and that reflec- 
tion should be thought of as an a pattern, a way to structure a software system in order 
to achieve dynamic adaptability and separation of concerns. Good object-oriented en- 
gineering is a means to build a reflective system, but this does not make it less reflective. 

One hopes that the controversy helped sharpen the arguments in favor of reflection, 
and might contribute to a widely agreed upon definition of reflection. 



Session on Meta-level Architecture: 

Summary by Pierre Cointe (Session Chair, Ecole des Mines de Nantes) 

Four talks has been given in this session. Most of them (the first three) addressed the 
issue of introducing reflective facilities in Java in order to deal with mobility and/or 
security. 

Q1 A Reflective Framework for Reliable Mobile Agent Systems. 

Takuo Watanabe, Amano Noriki and Kenji Shinboh (JAIST, Ishikawa, Japan) 

Takuo Watanabe gave the talk. 

na Iguana/J: Towards a Dynamic and Efficient Reflective Architecture for Java. 
Barry Redmond and Vinny Cahill (Trinity College, Dublin, Ireland) 

Barry Redmond gave the talk. 

mil Security and Meta Programming in Java. Julien Vayssiere (INRIA-CNRS-13S, 
Nice, France) 

m Reflective Actors for Mobile Agents Programming. Jean-Paul Arcangeli, Laeti- 
tia Bray, Annie Marcoux, Christine Maurel and Frederic Migeon (Universite Paul 
Sabatier, Toulouse, France) 

Frederic Migeon gave the talk. 

ca described the implementation of a Java experimental framework to model mo- 
bile agents (and in the spirit of Lead-H- providing dynamic adaptability). Reflection and 
AOP are used to separate non-functional features from the rest of the application. Mo- 
bility is considered as an aspect and every object has its own meta-object. One purely 
syntactical question was about the difference between a reflective framework (as used 
in the title of the paper) and a MOP. 

Go) described the current work of implementing Iguana in Java. A first imple- 
mentation of Iguana has been done in C++ and this current research explores issues in 
implementing Iguana for an interpreted language. The runtime intercession mechanism 
will be realized by providing a native code library which extends the virtual machine. 
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HD discussed the match hetween Java security architecture and Java meta-pro- 
gramming facilities. First, Vayssiere provided a very interesting survey about Java 
MOPs including OpenJava, Dalang/Kava, JavaAssist, MetaXa, Guarana and ProAc- 
tive (but not Iguana!). This survey was based on the compile/load/run-time separations. 
Then Vayssiere discussed how to protect Java security policies from reflection and, 
how to use Java MOPs to implement new security policies. 

ID discussed how to use actors (according to Hewitt|Agha definition) to program 
mobile agents and to provide a good paradigm to deal with mobility. Reflective archi- 
tecture has also been introduced to separate functional aspects from operational ones. 

Due to the number of talks and the to lack of time, there were only few questions. 
Most of them were about looking for a (Java) killer architecture dealing with security 
and mobility. 



Session on Middleware: Session Chair Takuo Watanabe/4/S7] Japan. 
Summary by Walter Cazzola and Shigeru Chiba 

A lot of position papers has been submitted related to this topic, but only three signifi- 
cant papers has been selected for presentation: 

m Reflective Implementation of non-functional Properties with the JavaPod Compo- 
nent Platform. Eric Bruneton, and Michel Riveill (INRIA, France) 

Eric Bruneton gave the talk. 

This work is focused on the separation and composition of functional and nonfunc- 
tional properties in a distributed framework. Issues left open from this talk are related 
to the role of reflection in their work, properties composition is achieved through a 
complex form of delegation. 

H The Role of Meta-Information Management in Reflective Middleware. Fdbio Costa, 
and Gordon S. Blair (Lancaster University, United Kingdom) 

Fabio Costa gave the talk. 

He presented the use of reflection for exposing various aspects of middleware con- 
figuration. Their architecture is based on a multi-model reflection framework originally 
developed by Okamura et al for the AL- 1/D language. They identified four meta-models 
in their ORB system and designed reflective interface for those models. They also dis- 
cussed the integration of their reflective features with the meta-object facility, which is 
part of the CORBA standard. 

t6n Using Reflection for Composable Message Semantics. Markus Hof (Johannes Ke- 
pler University Linz, Austria) 

Hof in his work has described how render remote invocations first class citizens, 
going a step further towards full polymorphism: the invocation of the same method can 
have different semantics on two objects of the same class. 
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During the discussion time, questions and comments from the floor were focused 
on whether reflection is the unique approach to the applications presented hy the speak- 
ers. Some radical comments were that the technique used by JavaPod is not reflection 
but delegation and that the architecture used by Hof’s system is traditional message 
filtering. These comments are not really true because their systems provide some meta 
information, which is not available at the base level. However, the speakers’ responses 
did not seem strong enough to convince people, especially from the outside of the re- 
flection community, of the usefulness of reflection in the middleware domain. 



Session on Program Transformation: 

Summary by Satoshi Matsuoka (Session Chair, Tokyo Institute of Technology) 

There were three papers in the session, all relevant to user-induced program transfor- 
mation, or in a more ‘reflective’ terminology “compile-time reflection”. 

H Declarative Meta-Programming for a Language Extensibility Mechanism. Johan 
Brichau (Vrije Universiteit Brussel, Belgium). 

This paper basically proposes to utilize declarative programming techniques for pro- 
gram transformation I compile-time reflection. More specifically, prolog-like predicates 
are utilized to program the program transformation over a parse tree in a declarative 
manner. Although the idea of using declarative programming for program transforma- 
tion is not new, its application to compile-time reflection, in particular to provide easy- 
to-use and possibly composable transformation, sheds some technical interest. Here are 
some of the technical points of interest for the paperjtalk: 

- Pro: Declarative specification of program transformers instead of procedural com- 
pile-time MOP is good. 

- Question: Difference with traditional prologjlogic meta-programming? Other com- 
pile-time reflective systems that also facilitate parse-tree transformation? Are the 
abstractions too low level? What about conflicting transformations? How about 
some traditional analysis? Do you want a different metalanguage or the same, since 
when this system is applied to C++ or Java it is really not ‘reflective’ in a true sense, 
since one will be using different languages. 

d Jasper: Type Safe Compile-Time Reflection Language Extensions and MOP Based 
Templates for Java. Dmitry Nizhegorodov (Oracle Corporation, USA) 

Jasper is essentially an attempt to introduce the sophistication of modern Lisp-style 
macros into Java, in a reflective manner (so that macros can be programmed in Java as 
well.) It has had some history of real industrial application at Oracle, and as such it has 
an extensive layered architecture, which also distinguishes itself from previous Java 
compile-time reflective systems such as OpenJava. It also introduces type-safe tem- 
plate mechanism into Java, with the ability to control the expansion in a sophisticated 
manner. Here are some of the technical points of interest for the paperjtalk: 
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- Pros: Layered architecture providing different levels of meta-programming abstrac- 
tions, well organized. Good ideas from Lisp Macros 

- Question: User experience — what layer would users like to use the most? Relation- 
ship with other Java reflective systems? What about the macro processing speed? 

(D On the Lightweight and Selective Introduction of Reflective Capabilities in Appli- 
cations. Remi Douence, and Mario Sudolt (Ecole des Mines de Nantes, France) 

Remi Douence gave the talk. 

The final paper does not really focus on allowing user-defined program transforma- 
tions, but rather on introducing reflective ‘hooks’ into existing Java code for computa- 
tional reflection via program transformation. While this can be done rather straightfor- 
wardly and potentially useful, there are some potential technical problems as described 
below: 

- Pro: Selective reification is lightweight. 

- Question: Difference between previous systems, that have performed “selective 
reification” in the past, such as ABCL/2, and in particular Okamura & Ishikawa’s 
AL-1 and AL-l/D? Is this not too straightforward, potentially introducing over- 
head? Will this destroy the basic class abstraction & encapsulation (e.g. field ac- 
cess) such that we lose separate compilation, etc.? 

In the discussions period, one of the main issues was in line with what had been 
raised in Gil Bracha’s session — what kind of real-life impact each system will have, 
in terms of their advantages over existing solutions, andjor previous reflective systems. 
In this respect Jasper holds advantages over the other two systems, since it is already 
applied to a real product and the others are still quite experimental. As such many 
questions focused on how Jasper is being used in a real setting, and it was presented 
that Jasper templates and macros are used heavily as is with traditional C++ templates 
or Lisp macros. Thus, the utility question was answered in a very positive fashion, 
but as to what style of compile-time meta-programming would be considered ideal or 
advantageous remained an open question. 



2 Reflection Trends: The Organizers’ Opinion 
Summary by Shigeru Chiba (University ofTsukuba) 

In this summary, I would like to describe some issues that I thought were interesting 
during the workshop. 



Middleware 

Reflection is an active research issue in the middleware field. This workshop received a 
number of paper submissions from this field. 
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During this workshop, I was wondering what reflection means in the middleware 
field. In the language field, reflection means the ability to query an object for its class, 
methods, fields, and so on (introspection), and to modify a program by changing meth- 
ods and class definitions (program transformation). This ability, which allows us to ac- 
cess non Ist-class language constructs (Jacques Malenfant reminded us of this classic 
definition. Although many participants did not seem to like this definition, I think this 
is the clearest definition at least in the language field), has clear value even in industry. 

One of the issues confusing me was differences between reflective middleware and 
modular middleware. Here, modularity means that middleware components can be re- 
placed on demand and connected to other components for extension. Is reflection a 
technique for building modular middleware? I think the answer should be yes but I do 
not think that the middleware papers in this workshop presented a reflective technique 
for implementing modular middleware. Rather, they seemed to use “reflection” just as 
an alias of the word “modularity.” Many techniques presented in those papers were 
categorized into traditional delegation and filter. 

I thought that the classic definition in the language field could be also useful in 
the middleware field. If we find non Ist-class data that we want to access at runtime, 
we could develop something other than delegation and filter in the middleware field. 
Remember that even transparent method interception, which is a typical reflective tech- 
nique, reifies non Ist-class data such as parameter types (marshaling). Fabio Costa’s 
presentation ih gave us another hint. He mentioned the use of reflection for managing 
type repository, which is a non Ist-class data structure. Version management based on 
interface types might be a good application of reflection in the middleware field. 

According to Jacques Malenfant’s comment, reflection is useful if an unexpected ex- 
tension is needed in future. Is surveying the history of middleware helpful for reflection 
research? 

Security 

Julien Vayssiere’s presentation “Security and Meta Programming in Java” HD was 
good survey. He rose two distinct issues: (1) how we protect systems from reflective 
computation, and (2) how reflection can be used for protecting systems. The former 
issue is relatively classic and well known but the latter issue is still open. 

As for the former issue, he mentioned that existing reflective Java systems, such as 
OpenJava, Kava, and MetaXa, can potentially cause security problems. 1 agree to this 
argument since, in principle, reflection is a technique for accessing protected internal 
data structures. However, I do not think that those security problems are really problems 
in practice since the reflective capability is provided for only secure programs, such as 
a configuration program written by the users. Malicious programs cannot use the reflec- 
tive capability. Reflective computation can cause a security problem only if malicious 
programs break the protection mechanism and use the reflective capability. We should 
rather discuss how to prevent malicious programs from using the reflective capability. 

For protecting systems from security flaws caused by programmers’ mistakes, load- 
time reflection is a reasonable trade-off point in Java. It is more adaptable than compile- 
time reflection since it is executed later. On the other hand, it is more secure than run- 
time reflection using a customized JVM since it can exploit a bytecode verifier. Even if 
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the result of reflective computation is an invalid program, the bytecode verifier denies 
loading it into the virtual machine. However, some applications need runtime reflection. 
They need program transformation not at the bytecode level but at the assembly level 
and thus they need the reflective capability to customize the virtual machine at runtime. 
The best reflective architecture depends on applications. 

The latter issue raised by Julien Vayssiere was more interesting. Although he did 
not talk much about this issue, I think that using reflection for protection mechanisms 
can be significant applications of reflection. Security seems an orthogonal aspect of 
program against application logic. Reflection would be a good tool for describing a 
complex security policy. 

Existing applications in the security field are not recognized as killer applications 
of reflection. For example, as Julien Vayssiere pointed out, a metaobject intercepting 
method invocations is known as a good platform for implementing an access control list 
(ACL) but that is not a killer application. Why? Probably, the reason is that it does not 
solve any problem. Although it seems good from the viewpoint of software architecture, 
it does not provide a faster ACL implementation than traditional ones or make it easier 
for the users to write a security policy. It does not verify that the security policy includes 
no security hole. Furthermore, I’m not sure that it is a good architecture even from the 
implementation viewpoint. 

Program Translation 

Dmitry Nizhegorodov was a contributor from industry. His presentation “Jasper: Type- 
Safe MOP-Based Language Extensions and Reflective Template Processing in Java” a 
was about a reflective programming tool Jasper, which he is using for developing real 
products. 

Reflective (i.e. programmable) program translators such as Jasper are obviously 
useful in practice. However, I was wondering that it is really feasible to use such a 
language-extension tool (without commercial supports) for software development by 
a large number of engineers. A program written in an extended language is difficult 
to read for team members who do not know the extensions. Like the excessive use of 
macros, the excessive use of language extensions is a negative factor of team collabo- 
ration. 

In the discussion, I asked him this question. His answer was clear; he used Jasper for 
writing his code but he never shared the source code of Jasper with his team members. 
He said that he shared only the code produced by Jasper with his team members. Since 
the final stage of Jasper is a pretty printer, his team members can see only a formatted 
program written in the regular Java language. 

Although Jasper is an extended Java compiler, his way of using Jasper reminds me 
of Emacs commands, which automate typical processes of text editing and assist us 
to write a program. The commands are used only during writing a program and the 
resulting program does not include any commands as the output of Jasper does not 
include any syntax extensions. The commands can be personalized; team members do 
not have to use the same set of Emacs commands. Syntax extensions by Jasper are 
similar to Emacs commands. Sharing complex syntax extensions among team members 
is not realistic if the team size is big, but personally using those extensions should 
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be acceptable. I thought that Jasper showed one of the ways of promoting the use of 
reflective program translators in industry. 

Summary by Walter Cazzola (University of Milano Bicocca) 

In this summary, I would like to try weighing up what has been emerged from the 
workshop debates and focusing our attention on what I consider will be the future trends 
for research in object-oriented reflection. 

Software Engineering 

Reflection, thanks to its features, such as, separation of concerns, and transparency, is 
commonly recognized as a valuable instrument for developing, extending, and main- 
taining software. 

Structuring software in mostly independent layers which will be successively com- 
bined together with little coding efforts, encourages developers to either develop dif- 
ferent aspects of the application in different moments or entrust the development of a 
specific aspect to a different team. Such an approach improves: 

- software reuse, — because to combine and to adapt existing modules with | to the 
new applications, it is simpler than using modularity, 

- software stability, — the development of critical software’s aspects may be en- 
trusted to specialized teams or easily retrieved from well-known and tested library, 
and 

- software maintenance, — each aspect of the system is realized by a close (i.e., 
without, or with very little, dependencies with other subsystems) subsystem, whose 
code is more compact than the code of the whole system. 

Thanks to transparency it is also possible to reuse black box components. 

Thus, reflection, if well applied, helps to overcome typical problems related to soft- 
ware component integration, which hinder the spreading of software reuse. A lot of 
work has already been done to define reflective languages and reflective tools for cod- 
ing reflective systems. Unfortunately, very little has been done to define, or to extend, 
a methodology analogous to UML which helps in integrating reflective concepts since 
the software development early stages. 

I think that reflection’s future trends involve to shift up its concepts from the lin- 
guistic level to a methodological level, as it has already happened for object-oriented 
technology. To testify such a need there is the growing interest from people coming 
from software engineering field in reflection which has lead to some attempts (e.g., 
Suzuki and Yamamoto, Extending UML for Modeling Reflective Software Compo- 
nents, <UML ’ 99>) of modeling reflection in UML. 

Functional and Nonfunctional Requirements 

A typical open issue, related to consider reflection as a methodology and not simply 
as a development tool, is represented by the meaning of functional and nonfunctional 
features. 
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A basic criterion used to layerize an application consists in determining which fea- 
tures are not functional to the application requirements. Unfortunately a universal def- 
inition or a recognized taxonomy about what is or is not a functional feature doesn’t 
exist. A formal definition of functional or nonfunctional feature would help in estab- 
lishing what can be realized in the meta-level and would encourage to build libraries of 
meta-level entities up. 

Some interesting ideas have been proposed by the Bruneton, and Riveill’s work 0. 
But they only consider how to implement nonfunctional features, without giving an 
algorithm to determine what is or not is (or they consider to be) functional to the appli- 
cation. 

In my personal opinion the border between functional and nonfunctional features 
cannot be defined, because it depends on the application, i.e., what we consider non- 
functional for an application, can be considered functional to another. One idea to face 
this problem could be to outline a group of properties describing the concept of func- 
tional feature, and through such properties, to determine whether a feature is or is not 
functional, application by application. 

At the workshop, few works considered these issues, and proposed some solutions. 
In his work, Emiliano Tramontana, who unfortunately shouldn’t attend the workshop, 
has considered software’s evolution and maintenance through reflective techniques. 



Summary by Thomas Ledoux (Ecole des Mines de Nantes) 

Reflection: How and Why? 

How? According to Gilad Bracha and Shigeru Chiba, a few papers submitted to the 
workshop had little to do with reflection. Rather than using purely reflective techniques, 
they used mechanisms such as delegation or message filtering. Then, they provided 
good modularity but they did not deal with 1st class constructs. 

However, I want to be positive because some presentations gave a good idea of what 
is a reflective system (see I4I10I12I ). For example, the Iguana/J architecture is a promis- 
ing approach Eol . It deals with selective reification of behavior, run-time reflection and 
run-time efficiency. 

Now, the Java language and/or the middleware domain are a common denominator 
between several works in the reflection area. We can bet that technical and architectural 
issues will progress in the next years. 

Why? During the workshop, a recurrent question was “what is the killer application of 
reflection?”. Gilad Bracha challenged everyone to argue for the pragmatic value of the 
most advanced uses of reflection that researchers have proposed in recent years. What 
are the real interests of reflection? 

First, for SUN (cf. Java Reflection API) and lots of people, introspection has now 
clear value. Any interesting system has to query information on itself. 

Then, flexibity and adaptability are other benefits provided by reflection. Recent 
work and workshop presentations (see H7I9II 1 showed these advantages in the middle- 
ware domain. Why should middleware be reflective? Because reflection makes system 
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more adaptable to its environment and better able to cope with change. In a middle- 
ware context, the need to cope with change particularly arises when middleware based 
applications are deployed in dynamic environments such as multimedia, group com- 
munication, real-time and mobile computing environments (cf. the recent workshop on 
Reflective Middleware). 

Finally, reflection allows separation of concerns which is highly desirable to build 
open systems (cf. summary by Walter Cazzola). Integrating definitions of functional 
and non-functional properties via reflective concepts at the design level is a new and 
an interesting issue. An example of need of separation of concerns is the industrial 
components model EJB. An EJB container deals with code weaving of functional and 
non-functional properties. Thus, the needs of separation of concerns are crucial and 
reflection, if well applied, helps to structure a software system. 

In short, reflection has many good features. According to Gilad Bracha, reflective 
community has to prove the usefulness of reflection by demonstrating it as the best way 
to reduce time-to-market. 



Composition of Concerns 

One remaining main open issue is the composition of concerns. Distinguishing different 
abstraction levels, reflection helps separation of concerns. Some presentations empha- 
sized the separation of functional and non-functional properties (see Emi). Such an 
approach improves reusability and provides a “plug and play” environment for enabling 
adaptability. 

However, separation is a good idea if we can compose the separated concerns to- 
gether! 

In compile-time reflection, the composition of functional and non-functional prop- 
erties is materialized by transformation rules and is based on a kind of join points (like- 
wise in the AOP approach). In run-time reflection, this composition is materialized, 
in general, by trap calls. So, the composition between functional and non-functional 
properties owns a clear semantic. 

However, the composition of several non-functional properties has to be studied 
more in deep. How to combine different non-functional properties in a clean way by 
keeping the original semantic of each property? The order of composition can have 
a serious impact on the result. Eor example, the composition of the concern “encod- 
ing” with the concern “tracing” supposes a special order. Interferences between non- 
functional properties lead to unexpected (meta)-behavior and discredit the advantages 
provided by the separation of concerns. 

This problem was not mentioned at the workshop. At the design level, © suggests 
a composition model with the Strategy and Decorator design patterns. At the imple- 
mentation level, Q proposes a minimal composition model which should be clarified 
in the future. Researchers in the reflection area should be inspired by work on other 
fields such as mixin-based inheritance or AOR 
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3 Final Remarks 

This workshop main goal was to encourage people to present works in progress in the 
area of reflection and meta-level architectures. The workshop was lively and the debates 
were very stimulating. We hope that the workshop has helped researchers to mature 
their idea and we encourage the accepted papers to be submitted to the conference 
Reflection’Ol (http : //www. openj it . org/ref lection2001). 
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Abstract. Exception handling continues to be a challenging problem in object 
oriented system design. One reason for this is that today’s software systems are 
getting increasingly more complex. Moreover, exception handling is needed in 
a wide range of application systems, sometimes requiring domain-specific 
models for handling exceptions. Also, concurrency, distribution, and code mo- 
bility add new dimensions to the existing challenges in this area. The integra- 
tion of exception handling mechanisms in a design needs to be based on well- 
founded principles and formal models to deal with the complexities of such 
systems and to ensure robust and reliable operation. It needs to be pursued at 
the very start of a design with a clear understanding of the ensuing implications 
at all stages, ranging from design specification, implementation, operation, 
maintenance, and evolution. This workshop was structured around the presen- 
tation and discussion of the various research issues in this regard to develop a 
common understanding of the current and future directions of research in this 
area. 



1 Summary of Objectives and Results 

Modem object oriented systems are getting more complex and they have to cope with 
an increasing number of exception conditions representing abnormal situations or 
failures. The most general way of dealing with these problems is by incorporating 
exception handling techniques in the design. Over the past decade, several models and 
mechanisms for handling exceptions have been proposed and developed for object 
oriented (00) languages and systems, but there are still many open problems in ap- 
plying them in practice due to the complexity of exception code design and analysis, 
due to lack of methodologies supporting proper use of exception handling, and by not 
addressing exception handling at proper phases of 00 system development. 



J. Malenfant, S. Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 16-31, 2000. 
© Springer-Verlag Berlin Heidelberg 2000 
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Traditionally, over the past 30 years, the research in exception handling has centered 
around the design and implementation of programming languages. More recently, 
there has been an increase in research activities dealing with exception handling mod- 
els and mechanisms in a wide range of application systems such as databases and 
transaction processing systems, workflow systems, distributed object management 
systems, and concurrent systems. Besides the development of application-driven and 
domain-specific models for exception handling, the research activities in this area 
have been driven by the need for formal models of exception handling mechanisms to 
facilitate design and analysis of large-scale 00 systems. The aim of this workshop 
was to bring together the active and leading researchers in this area to develop a 
common understanding of the important research directions that are central to the 
various strands of research in this area. The last workshop on this topic at an ECOOP 
conference was about 10 years ago, therefore, we felt a clear need to provide a forum 
for the exchange of ideas to assess the important problems and future directions for 
research in this area. 

We aimed at discussing important topics of developing and using exception handling 
techniques in 00 systems and languages. We invited participants interested in dis- 
cussing their research on exception handling in areas related to 00 systems, in par- 
ticular: formal models, distributed and concurrent systems, practical experience, new 
application areas, mobile object systems, new 00 paradigms (e.g., 00 workflows, 
transactions), design patterns and frameworks, practical languages (Java, Ada 95, 
Smalltalk, BETA), open architectures, fault tolerance. 

The workshop was attended by 17 researchers who participated in the presentation 
and discussion of 14 position papers. These presentations and discussions were 
grouped into four thematic sessions. The first session (five presentations) addressed 
linguistic issues in the context of contemporary models and exploration of new ideas, 
the topics included reviews of various models for exception handling in programming 
languages, fault tolerant computing, aspect-oriented programming and distributed 
object management systems. The focus of the second session (three presentations) 
was on semantics and implementation issues. Presented works were related to type 
theory based formal specification - the semantics of the Java exception handling 
model, to the impact of exceptions on code optimization in compiling Java programs, 
and to the relationships between triggers in database systems with the conventional 
notions of exceptions. The focus of the third session (four presentations) was on is- 
sues related to concurrency, distribution, and mobility. These presentations addressed 
exception handling in mobile agent systems and concurrent transaction-oriented sys- 
tems. The global topic of the fourth session (two presentations) was the design, 
achievement and evolution of 00 systems in the presence of exception handling 
mechanisms. 

2 Participants 

Yolande Ahronovitz Universite Montpellier-II, France 

yolande@lirmm. fr 

Christophe Dony Universite Montpellier-II, France 

dony@lirmm.fr 
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3 Summary of the Call-for-Papers 

The call-for-papers for this workshop emphasized its broad scope and our desire to 
focus the workshop discussions on problems of "complexity" of using and under- 
standing exception handling: Why programmers and practitioners often believe that it 
complicates the system design and analysis? What should be done to improve the 
situation? Why exception handling is the last mechanism to learn and to use? What is 
wrong with the current practice and education? 

We invited the researchers interested in this workshop to submit their position papers 
aiming at understanding why exception handling mechanisms proposed and available 
in earlier 00 languages (discussed, for example, atEC00P'91 Workshop on "Ex- 
ception Handling and Object-Oriented Programming are not widely used now. We 



* Dony, Ch., Purchase, J., Winder. R.: Exception Handling in Object-Oriented Sys- 
tems. Report on ECOOP '91 Workshop W4. OOPS Messenger 3, 2 (1992) 17-30 
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were interested in papers reporting practical experiences relating both benefits and 
obstacles in using exception handling, experience in using advanced exception han- 
dling models, and the best practices in using exception handling for developing mod- 
em applications in existing practical settings. 

The original plan was to have up to 20 participants. We asked each participant to pre- 
sent his/her position paper, and discuss its relevance to the workshop and possible 
connections to work of other attendees. The members of the organizing committee 
reviewed all submissions. The papers accepted for the workshop sessions were posted 
on the workshop webpage so the participants were able to review the entire set of pa- 
pers before attending the workshop. 

Additional information can be found on the workshop web page: 

http://www.cs.ncl.ac.uk/people/alexander.romanovsky/home.formal/ehoos.html. 



4 List of the Workshop Papers 

1. Jorgen Lindskov Knudsen (University of Aarhus). Exception Handling versus 
Fault Tolerance 

2. Anand Tripathi and Robert Miller (University of Minnesota). An Exception Han- 
dling Model for a Mobile Agent System 

3. Andrew Stevens and Des Watson (University of Sussex). The Effect of Java Ex- 
ceptions on Code Optimisations 

4. Alexander Romanovsky (University of Newcastle upon Tyne) and Jorg Kienzle 
(Swiss Federal Institute of Technology). Exception Handling in Cooperative and 
Competitive Concurrent Object-Oriented Systems 

5. Anna Mikhailova (University of Southampton) and Alexander Romanovsky (Uni- 
versity of Newcastle upon Tyne). Supporting Evolution of Interface Exceptions 

6. Bjorn Egil Hansen (DNV) and Henrik Fredholm (Computas). Adapting C++ Ex- 
ception Handling to an Extended COM Exception Model 

7. Yolande Ahronovitz and Marianne Huchard (University of Montpellier). Excep- 
tions in Object Modeling: Questions from an educational experience 

8. Tatyana Valkevych and Sophia Drossopoulou (Imperial College). Formalizing 
Java Exceptions 

9. Marta Patino-Martinez, Ricardo Jimenez-Peris, and Sergio Arevalo (Univesidad 
Politecnica de Madrid). Exception Handling in Transactional Object Groups 

10. Alessandro F. Garcia and Cecilia M. F. Rubira (University of Campinas). An Ex- 
ception Handling Software Architecture for Developing Robust Software 

1 1 . Cristina Lopes (Xerox PARC), Jim Hugunin (Xerox PRAC), Mik Kersten (Xerox 
PARC), Martin Lippert (University of Hamburg), Erik Hilsdale (Indiana University) 
and Gregor Kiczales (University of British Columbia). Using AspectJ™ For Pro- 
gramming The Detection and Handling of Exceptions 
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12. Jorg Kienzle (Swiss Federal Institute of Technology). Exception Handling in 
Open Multithreaded Transactions 

13. Elisa Bertino (University of Milan), Giovanna Guerrini (University of Genova), 
and Isabella Merlo (University of Genova). Do Triggers Have Anything To Do With 
Exceptions? 

14. Christophe Dony (University of Montpellier). A Few Interesting Ideas Ignored (in 
Java) or Forgotten from the Past 



5 Thematic Classification and Summary of Contributions 

The workshop program was organized into four sessions. We summarize below the 
important ideas that were presented and debated in these sessions. 

5.1 Session 1: Linguistic Issues: Existing Models and New Ideas 

This session addressed linguistic issues of exception handling. The session was a 
mixture of presenting existing exception handling models in a new light, presenting 
existing models that have unfortunately been ignored for several years, along with 
new models of exception handling, such as those needed for applications built using 
component software. 

In his talk "Exception Handling versus Fault Tolerance", Jorgen Lindskov Knudsen 
discussed the many proposals that have been put forward on defining language con- 
structs for handling exceptions. Most of these are dynamic in nature (i.e. the exception 
is handled by some component found by examining the dynamic calling sequence 
leading to the exceptional occurrence), while others are static (i.e. the exception is 
handled by some component found by analyzing the static context of the exception 
occurrence). Jorgen Lindskov Knudsen then discussed dividing error handling into 
two distinct disciplines: exception handling and fault-tolerant programming. Excep- 
tion handling deals with the handling of well-defined error conditions within a well- 
defined system or framework. On the other hand, fault tolerant programming deals 
with error handling in all other cases: ill-designed systems, faults in the exception 
handling code, errors originating from outside the system or framework. Jorgen Lind- 
skov Knudsen then reported his experiences with the static exception handling 
mechanisms of BETA. He elaborated that static error handling is in fact an effective 
exception handling mechanism, but also that it is difficult (and in some cases impossi- 
ble) to use it for fault tolerant programming. Jorgen Lindskov Knudsen therefore pro- 
posed to introduce a dynamic error handling mechanism to be used for effective fault 
tolerant programming. On the other hand, he stressed that the static exception han- 
dling model should be used almost exclusively, since it gives the most well-designed 
exception handling, integrated with the 00 tradition, and reserve dynamic exception 
handling only to those cases where no other error handling solution can be found. 

In the second talk Christophe Dony discussed "A Few Interesting Ideas Ignored (in 
Java) or Forgotten from The Past". The aim of this talk was to remind the exception 
handling community of previous research results, that seem to have been ignored, 
more or less, in the current research - ideas that should not be forgotten, and which 
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might inspire future research. The first idea presented was related to the scope and 
extent of handlers. The work carried out for handling exceptions in procedural lan- 
guages such as PL/I, Clu, Ada or Mesa, has shown that modularity and the notion of 
fault-tolerant encapsulation rely on a stack oriented handler research, on the ability for 
signalers to raise exceptions to the operation callers, and for the callers to handle the 
exceptions raised by inner modules. However, Christophe Dony illustrated, that 
Smalltalk-80, in its standard blue book specification, has shown the utility of attach- 
ing handlers to object classes (let's call them class-handlers), providing an 00 style of 
handling exceptional situations and of extending and reusing code in which excep- 
tions are signaled. Christophe Dony also presented a way, implemented in its systems 
for the languages Lore and Smalltalk, to combine class handlers and a stack-oriented 
handler research discipline to combine both advantages. 

Secondly, Christophe Dony presented issues from the exception handling system from 
Flavors system. Flavors made it popular to describe exceptions as hierarchically or- 
ganized classes on which methods can be defined, allowing them to be called within 
handlers to deal with the corresponding exceptional situations in a standard way. De- 
rived from this principle, Christophe Dony discussed relationship between meta ob- 
ject programming (MOP) and exception handling: various system including Flavors, 
Clos, ParcPlace Smalltalk, Lore have proposed various MOPs allowing system devel- 
opers to adapt a language basic exception handling mechanism to the application par- 
ticular needs or to extend the language with new models (e.g. component model). 

Finally, Christophe Dony discussed communication protocols between signalers and 
handlers. The Flavors system proposed signaling protocols allowing signalers to 
specify, each time an exception is raised, which resumption solutions are currently 
available. Handler can then choose a specific resumption solution by invoking a cor- 
responding method defined on the current exception class. 

The following talk was by Bjorn Egil Hansen on "Adapting C++ Exception Handling 
to an Extended COM Exception Model". Bjorn Egil Hansen discussed the BRIX ex- 
ception system which was designed with the following objectives: to simplify and 
minimise the amount of code needed for exception handling; to increase system ro- 
bustness and correctness; and to increase flexibility in system configuration and evo- 
lution. By having a notion of both specified and unspecified exceptions, the BRIX 
exception model allows recovery from more situations than those typically specified 
in an abstract interface. Exceptions from a component are categorised according to 
two orthogonal criteria: (i) component state: controlled or uncontrolled and (ii) cause 
of exception: operational or implementation. Only in the case of controlled opera- 
tional exceptions should the developer make an effort to mask the exception or to 
recover and propagate the exception to increase the overall robustness of the system. 
For the other cases this is generally a waste of effort and the cause of the exception 
should instead be eliminated, i.e. by fixing lower-level bug or allocating required re- 
sources. The BRIX exception system gives extensive support for doing exception 
handling in C++ in a COM environment according to the model above, providing 
mechanisms for: 

• conversion between COM and C++ exception representation 

• shorthand notation for various propagation and handling 
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• default mechanisms for typical situations 

• integration of pre/post-condition checking and general assertion checking 

• simple user-interaction enabling local handling of exceptions by involving user 

• rich support for logging of exceptional events, simplifying debugging both during 

development and operation and helping operators in identifying lack of resources. 

The fourth talk in this session "Using Aspect!™ for Programming the Detection and 
Handling of Exceptions" was delivered by Martin Lippert. Martin Lippert took an 
existing framework written in Java^“, the JWAM framework, and partially re- 
engineered some of its exception detection and handling aspects using AspectT“, an 
aspect-oriented programming extension to Java. Aspect-oriented programming (AOP) 
has been developed to provide programmers with mechanisms to implement, abstract 
and compose crosscutting concerns. AOP language design is based on understanding 
the structure of common crosscutting concerns and developing mechanisms that can 
capture that structure and can be composed to develop more complex crosscutting 
structures. Martin Lippert presented how Aspect!™ was used to re-implement the 
design-by-contract checks inside the JWAM framework, resulting in the amount of 
code used to implement the contract checks using “contract aspects” - aspects con- 
taining only the contract checking code - being considerably reduced. It was also re- 
ported, that the contract aspects reduce the risk of forgetting the proper contract 
checking implementation in a subclass without losing the possibility to redefine pre- 
and post-conditions using sub-aspects. Martin Lippert also reported using Aspect!™ 
to re-implement some Java exception handling code inside the redundancy framework 
since some redundancy was identified in those parts of the framework implementa- 
tion. Using an aspect to extract the exception handling code out of the functional im- 
plementation of the class, the exception handling code can be reused for more than 
one catch block over more than one class. As a result of the presentation there was 
some discussions about some general problems using AOP (e.g. the lack of good tool 
support) as well as the improvement of the presented quantitative numbers using not 
only the framework but also some applications build on top of the framework for the 
measurements. 

The last talk in this session was given by Cecilia Rubira on "An Exception Handling 
Software Architecture for Developing Robust Software". Fault-tolerant 00 software 
systems are inherently complex and have to cope with an increasing number of error 
conditions to meet the system dependability requirements. Dependable 00 software 
detects errors caused by residual faults and employs fault tolerance measures to re- 
store normal computation. The presence of exception handling facilities can reduce 
software development efforts since they allow software designers to: represent errors 
as exceptions, define handlers to deal with them, and use an adequate strategy for 
exception handling when the occurrence of an exception is detected. Moreover, 00 
systems may be consisted of various threads (or processes) executing methods concur- 
rently on objects. Exceptions are more difficult to handle in concurrent 00 systems 
than in sequential ones especially because of cooperative concurrency. That is, several 
concurrent threads usually cooperate to perform some system activity, giving rise to 
very complex concurrent interactions. The present interest in software architectures 
and design reuse motivated the authors to develop an exception handling software 
architecture for building fault-tolerant software. A software system quality require- 
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ments (such as dependability and persistence) are largely permitted or restrained by 
its architecture; so, the authors' believe that if an appropriate architecture (in particu- 
lar one that supports exception handling) is chosen since the outset of the design 
phase, then a proper use of exception handling throughout the development life cycle 
of a system can be obtained. The proposed architecture provides a generic infrastruc- 
ture that supports uniformly both concurrent and sequential exception handling. 
Moreover, the exception handling architecture is independent of a specific program- 
ming language or exception handling mechanism, and its use can minimise the com- 
plexity caused by handling abnormal behaviour. The architecture is composed of four 
well-defined components: the Exception component, the Handler component, the Ex- 
ception Handling Strategy component, and the Concurrent Exception Handling Action 
component. The structural and behavioural aspects of the components are described 
by means of a set of design patterns. The proposed patterns allow a clear and trans- 
parent separation of concerns between the application functionality and the exception 
handling facilities, easing the task of building fault-tolerant software with high assur- 
ance. 

The talks and the discussions tried to develop a clear relationship between various 
commonly used terms and concepts, particularly in regard to relationship and differ- 
ences between error handling and exception handling. Dependability community has 
concepts of faults, errors, failures and for these people exception handling is a means 
for tolerating faults. Knudsen’s talk characterised exceptions as anticipated failure 
conditions within a well-defme framework in contrast to errors which are unantici- 
pated conditions that arise due to faults or from outside of the design framework. The 
discussions ensuing from the this talk led to the conclusion that the static model of 
exception handling chain is found to be adequate in most cases except in cases de- 
signing fault-tolerant systems. Dony’s presentation reminded of many important re- 
search contributions made in the past in the area of exception handling in 00 systems. 
These past contributions in the area of exception handler scope, use of meta object 
programming, and flexible models to deal with different resumption requirements 
should not be forgotten. 

5.2 Session 2: Semantics and Implementation 

This session addressed issues related to formal descriptions of exception handling 
constructs in a modem language such a Java, impact of exception handling on code 
optimization during compilations of Java programs, and possible use of exceptions in 
Java-based 00 database management systems to realize database triggers. 

Tatyana Valkevych presented an overview of a formalization of the static and dy- 
namic semantics of Java related to exceptions in her talk on "Formalizing Java Ex- 
ceptions". The most challenging Java feature with respect to exceptions are the dual 
nature of exceptions whereby an exception may act as a normal object until explicitly 
thrown, and the difference beginning execution of a throw-statement and the actual 
throwing of the exception, whereby the latter exception may be different from the 
exception indicated after the throw-statement. This talk distinguished between normal 
execution, from which no unhandled exception escapes, and abnormal execution, 
from which an unhandled exception escapes. At the level of objects, one can distin- 
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guish those not thrown (these exhibit normal behaviour) and those which are thrown 
(these exhibit abnormal behaviour). This work develops an operational semantics that 
gives a concise and precise model of Java. In the type system it distinguishes normal 
types which describe the possible outcome of normal execution, and abnormal types 
which describe the possible outcomes of abnormal execution. The type of a term con- 
sists of its normal type and its abnormal type. In this approach the meaning of the 
subject reduction theorem is stronger than usual: it guarantees that normal execution 
returns a value of a type compatible with the normal type of the term, and that abnor- 
mal execution throws an exception compatible with the abnormal type of the term. 
The formal description proposed in this talk consists of half a page of operational 
semantics, which is considerably shorter than several pages in the language manual. 
The authors made the case that their description is a good basis for more precise and 
succinct language manuals of the future. 

In his talk on “Effect of Java Exceptions on Code Optimisations", Andrew Stevens 
outlined a support for exception based control flow in Java. This talk showed the ef- 
fect of this support on compiler driven static analysis in quantified terms. The frame- 
work used to support exceptions in Java programs is shown to exist at three levels; the 
language syntax, the bytecode class files and from within the Java Virtual Machine 
(JVM). A model was described that divides the types of exceptions that can be raised 
into three categories; explicit, implicit-synchronous and implicit-asynchronous. The 
explicit exceptions are those described by the 'throw' statement, implicit-synchronous 
are those caused by an instruction breaking a semantic rule of the language and im- 
plicit-asynchronous are generated by JVM internal errors or a Thread. stop call. The 
presentation continued by outlining some standard compiler analysis structures, 
namely basic blocks, control flow graphs and call graphs. The effect of the exceptions 
on these structures was described as follows. For basic blocks, an instruction that po- 
tentially generates an exception marks the end of the block. The control flow graph 
and call graph are structures that attempt to map potential routes through the execut- 
ing code. Since the destination handler of a raised exception depends on runtime type 
information and call context, the flow graphs must mark the destination as unknown 
(or dynamic). Further, Andrew Stevens outlined an experiment to show basic block 
sizes and flow graph dynamics with implicit exceptions enabled and disabled. The 
results show that such exceptions greatly reduce block sizes and increase the dynam- 
ics by a factor or four. Since both these effects can reduce the power of compiler op- 
timisations, a future system that reduces the number of potential exceptions is de- 
scribed. 

The third presentation in this session, "Do Triggers Have Anything To Do With Ex- 
ceptions?", was by Isabella Merlo. The 00 paradigm is playing a crucial role in get- 
ting the programming language and the database fields closer to each other. The Java 
programming language is establishing itself as the most popular 00 programming 
language, and the increasing need of persistently storing Java objects, through mini- 
mal modifications to applications, led most 00 database management systems 
(OODBMs) to develop a Java version. The ODMG standard also has been enriched 
with a Java binding. Current relational and object-relational DBMSs provide an im- 
portant functionality, namely triggers. This typical database functionality has no direct 
counterpart in 00 programming languages, and though trigger usefulness has been 
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recognised also in the 00 context and a considerable amount of research has been 
carried out in the area of active 00 databases, triggers are not supported in current 
commercial OODBMSs. A relevant feature of the Java language is represented by its 
exception mechanism, which represents a very powerful mechanism for handling error 
situations. Since one of the most relevant functionalities achieved through triggers in 
the database context is integrity constraint enforcement, the two notions seem to be 
potentially related. In her presentation, Isabella Merlo provided an overview of trig- 
gers, then compared it with exception handling. This presentation was followed by a 
long discussion on how the two notions can be related, and if the support of excep- 
tions can offer any help or insight towards the introduction of triggers in Java-based 
00 database management systems. This certainly remains an open question for fur- 
ther investigation. 

The session clearly highlighted the impact of exception handling in generating effi- 
cient code through code optimization. Also, in this session the relationship between 
triggers and exceptions generated quite an extended debate. 

5.3 Session 3: Concurrency, Distribution, and Mobility 

Developing exception handling models which are adequate for designing modem 
concurrent, distributed and mobile applications was the theme of the third session 
consisting of four presentations followed by a discussion. 

Anand Tripathi delivered the first position paper entitled “An Exception Handling 
Model for a Mobile Agent System”. Ajanta is a Java-based system for programming 
distributed applications using mobile agents in which agents encapsulate code and 
execution context along with data. A model for exception handling in mobile agent 
applications in the Ajanta system was presented. When an agent arrives at a server, 
the server creates a thread to execute the agent's method that was indicated in the 
transfer request. During its execution, an agent may encounter some exception condi- 
tions. Some of these may be anticipated by the programmer and handled within the 
agent's code. If, however, an exception is not handled by the agent, the exception is 
signalled to its server thread. To facilitate exception handling, associated with each 
agent is a guardian object, which is stationary in the system. The name of the guardian 
object appears in the agent's tamper-proof credentials. When an agent encounters an 
exception that is not handled by its code, it is co-located with its guardian. In this case 
the agent carries the exception object identifying the exception. On co-location, the 
agent invokes the report method of the guardian object and passes to the guardian a 
reference to itself The guardian can then examine the agent's state to perform the ap- 
propriate recovery actions. Developing of guardians is a responsibility of the applica- 
tion developers. Ajanta provides some additional mechanisms using which the guard- 
ian can perform application-wide recovery actions. For example, in an agent-based 
program consisting of a group of agents, the recovery action may require termination 
of some or all of the agents in a group when one of the group members encounters a 
non-recoverable exception. Developing exception handling mechanisms for mobile 
systems is a vital and difficult topic, unfortunately mobile system developers do not 
often pay enough attention to this issue. The research reported in this talk is in many 
respects unique as it offers a general exception handling mechanism which takes into 
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account the specific characteristics of such applications and because it has been de- 
signed together with the mobile system. 

In his talk "Exeeption Handling in Cooperative and Competitive Concurrent Object- 
Oriented Systems" Alexander Romanovsky outlined the exception handling mecha- 
nisms developed for concurrent 00 systems and showed likely directions of future 
research. This presentation emphasized that considerable effort has been devoted to 
developing exception handling models for sequential systems and that a common un- 
derstanding exists in many topies in the field. The situation is different in concurrent 
systems. Although several schemes combining concurrency and exception handling 
have been proposed, this research is still scattered and the majority of coneurrent sys- 
tems use sequential exeeption handling. It is the author's belief that the latter is ab- 
normal because exception handling features should correspond to the programming 
features used in system design. The ehoice of a way to introduce exception handling 
depends on the way concurrent systems are to be developed and structured because 
exception handling is an issue of the system design, and language features should as- 
sist in and impose proper design. Exception handling is closely coupled with program 
structure and therefore the way in which the dynamic execution of concurrent systems 
is struetured influences possible ways of introducing exception handling into sueh 
systems. Following C.A.R. Hoare, J.J. Homing and B. Randell, all concurrent systems 
are classified into cooperative, competitive and disjoint ones, with the corresponding 
stmcturing techniques such as atomic actions, atomic multithreaded transactions and 
blocks of code (the latter is effectively identical to the sequential system stmcturing). 
Several sehemes have been proposed for introducing first two approaches into con- 
current systems, but only rarely do they ineorporate exception handling features (few 
examples were discussed in the talk). And even when they do, they neither provide a 
general exception handling model nor fit the main prineiples of 00 programming 
properly. Although this is an area of very aetive research, there are still many unelear 
points and unsolved problems. A general eommon understanding does not seem to 
exist. Two following presentations, which extend in many ways the seminal research 
on Argus system, have addressed some of the topics discussed in the talk. 

In the next presentation "Exeeption Handling in Transactional Object Groups" Ri- 
cardo Jimenez-Peris proposed a model which combines transactions and group com- 
munication and includes an exception handling mechanism. Transactions and group 
communication are two fault-toleranee techniques that have evolved separately for a 
long time. However, these two techniques are eomplementary, and distributed systems 
can benefit from their integration. In particular, transactional object groups can be 
used in clustered systems to provide high availability and high performance transac- 
tional services. Replicated object groups can tolerate failures without interrupting 
running services increasing their availability. Co-operative object groups perform 
services in parallel taking advantage of distribution and thus, improving their per- 
formance. Exeeption handling meehanisms play an important role in this kind of sys- 
tems. Firstly, exeeptions ean be used in combination with transactions to cope with 
anticipated errors within a transaction by providing automatic backward recovery for 
unhandled exeeptions. Secondly, object groups can raise eoneurrent exeeptions due to 
their concurrent and distributed nature. In the proposed model exception resolution is 
used to yield a single exception to the client when several servers raise exceptions. 
New exception resolution algorithm is developed to resolve exceptions at two levels: 
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local and distributed. Local resolution is first applied to concurrent exceptions raised 
within an object. Then, distributed resolution is applied to resolve the resulting ex- 
ceptions of the object group. This two-level hierarchical resolution is more rational 
than a global resolution, because local exceptions that are more related among them- 
selves, are resolved first. This talk reported several important results which are out- 
come of an active research effort on extending transactional services with an ability to 
develop co-operative systems. It is very important that the authors have realised that 
new models to be developed in this area should always include features for disci- 
plined and powerful exception handling 

The last talk of the session "Exception Handling in Open Multithreaded Transactions" 
was presented by Jdrg Kienzle who proposed a new model for providing transaction 
support for 00 concurrent programming languages. This support is enhanced by a 
fiill-fledge exception handling mechanism incorporated into the transactional support. 
The aim of this research is to achieve a smooth integration of the native language 
concurrency and the transactional features, so that the use of the concurrency features 
provided by the programming language is not restricted inside a transaction. A new 
transaction model called Open Multithreaded Transactions that meets this require- 
ment was presented. Threads inside such a transaction may spawn new threads, but 
also external threads are allowed to join a running transaction. A blocking commit 
protocol ensures that no thread leaves the transaction before its outcome has been 
determined. Exceptions can be handled locally by each thread. Unhandled exceptions 
crossing the transaction boundary cause the transaction to abort. Exceptions are 
propagated to all participant threads when a transaction aborts. An Ada 95 imple- 
mentation of this model is under development now. Although the discussed results are 
preliminary, they are important to researchers and practitioners because of two main 
reasons: this transactional model offers a good balance of the ways multiple transac- 
tion participants are affected by each other’s exceptions and because this model can 
be applied in any concurrent language (e.g. in Java). 

5.4 Session 4: Design and Evolution 

The last session was dedicated to the design and evolution of 00 programs dealing 
with exceptions. 

In the first presentation, Yolande Ahronovitz brought to the fore the important issue 
of how to design hierarchies of exception classes. Almost all 00 languages now rep- 
resent exception as classes and occurrences of exceptional situations as instances of 
these classes. This idea can be found in Nixon’s thesis and has been developed in 
various systems such as the Flavor one in the 1980s, it provides a simple way to de- 
fine both the internal representation and behavior of exceptions occurrences with ca- 
pabilities for extendibility and reusability. If many things have been said on the bene- 
fit of such an organization, the problem of modeling exception classes has not been 
studied much: literature gives good advice, but lacks concepts about how to think up 
exceptions, and UML lacks concepts to model exceptions as classes. Anyone that has 
written an 00 application has been confronted to issues such as the following ones: 
Should I have an abstract exception class for my whole application? Should I create 
an abstract class "StackException" generalizing all the exceptions related to the 
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"Stack" class I am designing? Should "StackException" be a subclass of "MyAppli- 
cationException" or of "CollectionException"? Should the various exceptions related 
to the Stack class be represented by slots of "StackException" or by subclasses? 
Yolande Ahronovitz and Marianne Huchard have proposed a kind of guide, based on 
object model elements, for finding exceptions at modeling stage, and for organizing 
them into classes hierarchies. More precisely, they have proposed to define a general 
exception class ExcTypeX for each type X found in a program, that exception being 
the root of all exception classes associated with X. Under this general root are defined 
a subroot for each feature associated with X: primitive attribute, method, association 
with other type Y. For an association, two subroots are created: one for the exceptions 
which encapsulate Y's exceptions and one for the exceptions which are induced by the 
association itself. In order to reflect the classes hierarchy of the application, if SX is a 
subclass of X, the general root ExcTypeSX is a subclass of ExcTypeX. Exceptions as- 
sociated with SX can either be related to its own features, or be specializations of ex- 
ceptions defined on inherited features, or be exceptions generated by new constraints 
on inherited features. These cases are distinguished in the hierarchy built under 
ExcTypeSX. The last case (new constraints on inherited features) is not allowed in 
many programming languages (e.g. Java, C-I-+). The way the hierarchy is built gives a 
possible solution to handle it. The complete hierarchy must not necessarily be entirely 
implemented; yet, it is helpful in accurately handling exceptions. Besides this guide, 
an original model of composite exception has also been proposed, to allow users to 
signal several problems at the same time. 

Towards the end of her presentation, Yolande Ahronovitz raised several important 
issues related to her work, and these issues were discussed during the workshop ses- 
sion. Certainly, the main issue is how to merge the type-based classification of excep- 
tions, presented in this session, with semantically-based exception hierarchies as 
found in other systems. For example, it is usual to classify exceptions according to the 
way they can be handled (fatal or recoverable exceptions) or to classify them around 
semantic categories (arithmetic exceptions, file-system exceptions). Both classifica- 
tions could cohabit provided that the implementation language supports multiple in- 
heritance. 

The second talk of this session was presented by Anna Mikhailova. Her talk on "Sup- 
porting Evolution of Interface Exceptions" focused on problems connected with the 
evolution of 00 applications in presence of methods signaling exceptions. Interface 
exceptions are explicitly declared exceptions that a method can propagate outside. 
Evolution in 00 systems is achieved via sub-classing and method overriding. When 
sub-classing is done without conforming to sub-typing rules, runtime type exception 
can occur. That is why languages wanting to statically check that programs are type 
safe imposes constraints on subclassing and overriding rules (e.g. contravariance or at 
least invariance for methods parameters types). In presence of exceptions, to be type- 
safe, an overriding method interface exception should not include exceptions that are 
not declared by its corresponding overridden one. Java, for example, imposes such a 
rule. Indeed, clients of a server class are only prepared to handle the exceptions ex- 
plicitly declared in the interface of this class and might be unaware of the existence of 
its subclasses. If a subclass of the server class signals new exceptions and if it is 
passed by subtyping to the client, the client might get invalidated, as it will be asked 
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to handle an unexpected exception. In her talk, Anna Mikhailova explained, via a 
convincing example, why it is desirable to introduce new exceptions in subclasses and 
proposed two complementary solutions to achieve this in a type-safe way. To solve 
the problem of non-conforming interfaces resulting from the addition of new excep- 
tions, the first proposal uses what she calls "rescue handlers". Rescue handlers are 
some kind of class handlers (see section 5.1) and are default handlers. They are in- 
voked when an exception is signaled within a method of the class the handler is asso- 
ciated with and when the method client does not itself provide a handler. Thus, when 
clients do not know how to deal with new interface exceptions of their servers, the 
rescue handler attached to the server class steps in to rescue the situation. Secondly, 
while rescue handling is suitable for the top-down system development approach, 
when there is a need to introduce an interface exception in a development step, it is of 
little help in a bottom-up approach. In this case, the author proposed to apply a classi- 
cal forwarding technique (the wrapper pattern) which is an architectural solution used 
for solving closely related interface mismatch problems. 

It was noted that a general solution to the evolution problem would be to systemati- 
cally define an exception signaled in a subclass method as a sub-exception of an ex- 
ception signaled in the corresponding superclass method. This would correspond to 
the organization of exception hierarchies suggested by Ahronovitz and Huchard. Un- 
fortunately, this is only possible when the subclass wants to signal a new exception 
and not an existing one. 



6 Conclusions 

The 1970s have seen the development of exception handling systems dedicated to 
procedural programming. Such tools and the associated mechanisms have been de- 
signed to enhance software reliability, reusability, readability and debugging. The 
1980s have seen the emergence and dominance of the 00 technology that has brought 
new ways to make program modular and reusable. During the 1980s and 1990s, ex- 
ception handling systems were integrated into all 00 languages. The first ECOOP 
workshop on exception handling and 00 programming held in 1991 was oriented 
towards the specification, understanding and implementation of these systems. The 
wide range of topics addressed by the participants of this new workshop has shown us 
many new research directions for exception handling in 00 systems. 

The year 2000 workshop proposed a clear representation of many open and challeng- 
ing problems that need to be understood and addressed by the programming language 
designers, software engineers, and application system programmers. Many problems 
still exist, and there are many new research opportunities in a variety of emerging 
application domains where exception handling mechanisms have to be application 
specific. The main conclusions gained from the presentations and discussions held 
during the workshop are as follows: 

• The evolution of exception handling models for standard 00 programming is still 
an open issue: 
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• A new model for BETA has been presented that proposes an interesting mix 
of static and dynamic handler research allowing BETA to deal separately and 
differently with failures and exceptions 

• Handlers associated with classes, as invented in the 1980s, have disappeared 
from C++ and Java.These kinds of handlers could be reinvestigated because 
of their intrinsic interest and because it has been shown that they could solve 
problems related to evolution in presence of static typing 

• More generally, the workshop also reminded the participants that many of 
the important past contributions are forgotten and the community should re- 
investigate their utility 

Today’s tendency is to use statically-typed 00 languages and to look for formal 
models for the integration and use of exception handling in fault-tolerant systems. 
A set of new research activities is advocated towards the definition of exception 
handling systems compatible with static and correct typing in 00 languages. Be- 
sides, the quest for formal models and type safety gives rise to great challenges in 
the presence of some models such as the resumption. These models, although in- 
teresting in term of expressive power, makes program analyses very complex, and 
might therefore be abandoned (or better formalisms should be developed) 

The representation of exceptions by hierarchically organized classes is now quite 
a standard but the design issues related to that representation are not solved and 
design languages such as UML do not correctly take it into account. There is a 
lack of proper frameworks and principles for designing and analyzing exception 
hierarchies and exception code in large-scale systems. The separation of the main 
code of the program from the exception code is an old issue for which new ad- 
vances can be considered thanks to new techniques for the separation of concerns 
in programming, such as aspect-oriented programming 

New linguistic mechanisms are needed which take into account recent develop- 
ments in designing new excerption handling mechanisms for concurrent, distrib- 
uted, web and mobile 00 systems. Future languages intended for such applica- 
tions should incorporate adequate exception handling mechanisms 
Exception handling mechanisms should be adequate to the language paradigm 
and the main language features (e.g. inheritance, concurrency), to the system de- 
velopment techniques, to the way systems are structured and to the application- 
specific characteristics of the system to be designed 

Safety of exception handling mechanisms is the prime concern which should be 
taken into account while developing new mechanisms, because exception han- 
dling mechanisms are often chosen for developing modem complex applications 
with high dependability requirements 

Exception handling is not just a linguistic issue. There is a need in applying dis- 
ciplined exception handling at all phases of the system development. To do this 
properly the methodologies should support a smooth transition between models 
used at different phases 

Another promising direction of the research in this area is to enforce good devel- 
opment techniques which use exception handling with a set of well-developed ar- 
chitectural and design patterns and idioms; this can serve as a sound solution 
complementing research focused solely on developing new linguistic approaches 
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• New flexible exception handling mechanisms applicable in all phases of system 
development should be developed; such mechanisms should be both general and 
flexible enough to allow for simple adjustment or customization 

• It is difficult to expect that the research community will come up with a linguistic 
mechanism which can solve all current and future problems, this is why research 
on integration of exception handling mechanisms found in different languages, 
systems and methodologies (e.g. Java and CORBA) is getting more important 

The workshop was a clear success in its primary goal of creating a forum to discuss 
and debate the important research directions in the area of exception handling in ob- 
ject systems. The wide range of topics addressed by the participants was a clear repre- 
sentation of many open and challenging problems that need to be understood and ad- 
dressed by the programming language designers, software engineers, and application 
programmers. 

Finally and most importantly, this workshop reinforced everyone’s view that such 
meetings are of tremendous value to the research community to provide a forum for 
direct and quick exchange of ideas on the importance of various issues and problems 
facing the community. The participants felt that it would be beneficial to have another 
meeting on this topic in the next 2-3 years. 

Acknowledgements: The authors want to thank the participants for making this workshop a 
success with their unique contributions. This report reflects the viewpoints and ideas that were 
contributed and debated by all these participants. Without their contributions, neither the 
workshop nor this report would have materialized. 
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Abstract. ECOOP-OOOSWS workshops aim to bring together research- 
ers and developers working on object-oriented operating systems and to 
provide a platform for discussing problems arising from the application 
of object-orientation to operating systems and solutions for them. This 
paper summarizes ECOOP-OOOSWS’2000 with its invited talk, nine 
paper presentations and lively discussions between and after them. 



1. Introduction 

1.1. ECOOP-OOOSWS Scope and History 

The first ECOOP Workshop on Object-Orientation and Operating Systems was 
held at ECOOP’97 in Jyvaskyla, Finland m- It was organized by Frank Schu- 
bert, Lutz Wohlrab, and Henning Schmidt. 

Since it provided a good forum for interesting discussions, the participants 
suggested that this workshop be periodically organized. At ECOOP’98 (which 
did not have a OOOSWS) Francisco Ballesteros and Ashish Singhai joined the 
organizing team. 

The second ECOOP Workshop on Object-Orientation and Operating Sys- 
tems was held at ECOOP ’99 in Lisbon, Portugal. It was organized by Lutz 
Wohlrab, Francisco Ballesteros, Henning Schmidt, Frank Schubert, and Ashish 
Singhai. Dario Alvarez and Reinhard Meyer joined to organizing team for 
OOOSWS’2000 during ECOOP’99. 



J. Malenfant, S.Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 32 4401 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 
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The scope of ECOOP-OOOSWS workshops includes topics like: 

— adaptable and adaptive OOOS, 

— frameworks for OOOS, 

— architecture of OOOS, 

~ distributed OOOS and middleware, 

— Aspect orientation and OOOS design, 

— what are the penalties of 00 in OS and how to avoid them, 

— reflective OOOS, 

— OOOS tools, 

— reusability and interoperability of OOOS components, 

— OOOS configurability, maintenance, tuning, and optimization, 

— OOOS for embedded systems, 

— real-time OOOS. 

In OOOSWS prospective participants submit a position paper. Submitted 
papers are reviewed by the organizers. Participation is by invitation only, the 
number of participants is limited to facilitate lively discussions. 

A distinguished member of the OOOS community is asked to give an in- 
vited talk. Authors of accepted papers give either a full talk or a short position 
statement. Discussion happens between the presentations and at the end of the 
workshop. 



1.2. ECOOP-OOOSWS’2000 

The invited talk was given by Marc Shapiro, of Microsoft Research Laboratory in 
Cambridge UK. Besides Marc’s talk, ECOOP-OOOSWS’99 had 9 talks and was 
attended by 15 participants from different parts of the world. The participants 
were: 

— Marc Shapiro, Microsoft Research Laboratory in Cambridge UK. 

— Alan Dearie, School of Mathematical Sciences, University of St. Andrews, 
North Haugh, UK. 

— Santiago Eibe, Universidad Politecnica de Madrid, Spain. 

— Maria A. Diaz Fondon, Lourdes Tajes, Fernando Alvarez y Dario Alvarez, 
University of Oviedo, Spain. 

— Paniti Netinant, Illinois Institute of Technology, USA. 

— Rolf Neugebauer, University of Glasgow 

— Ian Piumarta, Inria Rocquuencourt, France 

— Greg Law, City University, UK. 

— Frank Matthiys, Katholieke Universiteit Leuven, Belgium. 

— Reinhard Meyer from University of Magdeburg, Germany; 

— Francisco Ballesteros from University Rey Juan Carlos, Madrid, Spain, 

— Ashish Singahi, Cisco Systems, USA. 
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The paper presentations were structured into four sessions: 

1 . “Reflection” , 

2. “Other paradigms”, 

3. “Configurability”, and 

4. “Performance” . 

Before the sessions, we had the invited talk, and between and after the sessions 
we had discussion time. 

The rest of this report is structured as follows. Section [1] sketches the invited 
talk. Section [I] gives an account of each paper presentation given. Section |T] 
summarizes the discussions and is followed by the conclusion of the report. 



2. Keynote Speech: Experience with the PerDiS 
Large-Scale Data-Sharing Middleware 

Keynote speech by Marc Shapiro 
marc . shapiro@inria.fr 

PerDiS is a distributed persistent middleware platform, intended to ease 
the distributed sharing of long-term data. Its users belong to geographically- 
distant and non-trusting enterprises. It targets CAD applications for the building 
industry: data sets are large and pointer-rich; simultaneous reads and updates 
are supported; there is no central database; migrating legacy applications is 
performed by unskilled programmers. It has a very simple API and supports 
efficient access to shared data. Its central abstraction is a fine-grain, persistent, 
isolated shared memory, although the system mechanisms are coarse-grained, 
loosely-coupled and optimistic. We have found our dual-granularity model to be 
successful as it provides both an intuitive programming model, efficiency, and 
manageability. A number of real applications have been either ported or written 
specifically for PerDiS. Isolation and optimistic operation respond to application 
requirements and are essential for scalability. 

Marc pointed out how the key issue to get the framework running was to 
exploit carefully the way that users are known to work with the tool. Otherwise, 
communication would be just to costly. Clustering of objects is done so that we 
exploit the way they are used. 



3. Paper Presentations 

3.1. Session “Reflection” 

This session included paper presentations and discussions related reflection on 

OOOS. The papers exploited the use of reflection to provide new services, or 
tried to simplify the use of reflective facilities by means of libraries. 
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Introducing Distribution in an OS Environment of Reflective OO Ab- 
stract Machines 

(Fernando Alvarez et. al.) Paper by Fernando Alvarez Garcia, Lourdes Tajes 
Martinez, Maria A. Diaz Fondon, and Dario Alvarez Gutierrez. Fernando pre- 
sented the paper P 

Distribution is a key property for future Integral Object-Oriented Systems 
(lOOS) based solely on the Object-Oriented paradigm. The introduction of ob- 
ject distribution in the lOOS is not trivial if we want a clear distinction between 
mechanisms and policies and even more if we want policies to be easily replaced 
or customized. The authors have found that reflection is a well-suited technology 
for endowing the lOOS with such a distribution property. 



Implementing Self-Managing Protection Domains in Charm 
(Alan Dearie et. al.) Paper by Alan Dearie and David Hulse. Alan Dearie 
presented the paper 

They believe that the engineering of mobile or persistent processes is hindered in 
many systems by the amount of coupling between user- level and the kernel. This 
coupling usually takes the form of user level data structures containing opaque 
references to kernel data structures. In this paper they showed how self-managing 
protection domains may be constructed that support a modern object-oriented 
application environment that is not closely coupled with the kernel. This is 
achieved through the introduction of a software artifact called the Umbrella 
that abstracts over the low-level aspects of self-management and present a clean 
object-oriented management interface to the upper layers of software. They did 
talk about how the Umbrella is engineered and some of the problems that must 
be overcome in order to achieve isolation from the kernel. They concluded by 
showing how a thread system may be constructed above the Umbrella. 



3.2 Session “Other Paradigms” 

We had talks about single address space operating systems, virtual- virtual ma- 
chines, and new abstractions. 

The talks exposed operating system models which were different from the 
ones we use. 



Supporting Foreign Personalities in a Single Address Space Operating 
System 

(Rolf Neugebauer et. al.) Paper by Rolf Neugebauer and Richard Black. 
Rolf presented the paper |0] 

Traditional operating systems provide fixed abstractions to application de- 
velopers and users. Recent efforts in operating system research have focused on 
providing more flexibility and new functionality to applications. In their talk 
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they reported on an approach which allows execution of programs simultane- 
ously in distinct and well defined run-time environments called personalities. 
Personalities are constructed from a number of components. Components can 
be developed independently and are linked together at run-time to form the 
execution environment of an application. 

They have implemented a number of these components, forming a UNIX like 
personality, in a single address space operating system called ‘Nemesis’. Neme- 
sis’ programming model is object-based, based on closures. This satisfies both 
good software engineering practice and the special requirements of the single 
address space. This paper focuses on the issue of linkage between components 
and the issues of providing traditional APIs, such as UNIX, in a single address 
space operating system. They argue, that the object-based implementation of 
components is beneficial in such an environment. 



Highly Configurable Operating Systems: The VVM Approach 
(Ian Piumarta et. al.) Paper by Ian Piumarta, Bertil Folliot, Lionel Sein- 
turier, and Carine Baillarguet. Ian presented the paper m 



Applications, especially distributed ones, have become more and more com- 
plex during the last decade. One cause of this is the increasing number and 
complexity of system components — for communication, fault tolerance, mobil- 
ity, replication, and so on. At the same time, development environments (oper- 
ating systems, software communication busses and programming languages) are 
changing rapidly and place stringent requirements on developers. Their response 
to this challenge is a multi-language, hardware-independent execution platform 
called the virtual virtual machine (VVM). The essential characteristic of this 
platform is dynamic extensibility and reconfigurability to suit the needs of each 
application. 



Off-| — h: The Network in a Box 

(Francisco Ballesteros et. al.) Paper by Francisco Ballesteros, Fabio Kon, 
and Roy Campbell. Francisco presented the paper [T] 

The current computing platform is made of multiple heterogeneous devices in- 
terconnected through the internet. Devices present a great variation of resource 
availability, which changes over time. Therefore, it is difficult to build applica- 
tions for this platform. 

Applications and programmers must deal with the multiplicity of interfaces 
involved in the required resources. The job gets more complex if the application 
must adapt to changes in resource availability, which is becoming increasingly 
common. 

They are building Off-|— 1-, an OS kernel that makes network resources and 
automatic adaptation available to application and middleware programmers. 
Off-1— I- services are available natively on Intel platforms but could be emulated 
on top of other operating systems such as PalmOS and Linux. 
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3.3 Session “Configurability” 

We had talks about how to configure the system and how to use aspect orienta- 
tion to aid in the design of operating systems. 



Supporting Aspectual Decomposition in the Design of Operating Sys- 
tems 

(Paniti Netinant et. al.) Paper by Paniti Netinant, Constantinos A. Con- 
stantinides, Tzilla Elrad, and Mohamed E. Fayad. Paniti presented the paper [8] 

Supporting separation of concerns in the design of operating systems provides 
a number of benefits such as reusability, adaptability, extensibility and reconfig- 
urability. However, in order to maximize these benefits, such a support is diffi- 
cult to accomplish. Some aspects in operating systems such as synchronization, 
scheduling, and fault tolerance cut across the basic functionality of the system. 
In every layer these aspects might need to be modified. By separating the dif- 
ferent aspects of operating systems in every layer, they provide a better generic 
design model of operating systems. Aspect-Oriented Programming is a paradigm 
proposal that aims at separating components and aspects from the early stages 
of the software life cycle, and combines them together at the implementation 
phase. However, aspect-oriented software engineering can be supported well if 
there is an operating system, which is built based on an aspect-oriented design. 
Treating aspects, components, and layers as two-dimensional models is not a 
good design model. Two-dimensional models lead to inflexibility, limit possibil- 
ities for reuse, and make it hard to understand and modify. In this paper they 
propose an aspect-oriented design framework, which simplifies system design by 
expressing its design at a higher level of abstraction. Their work concentrates on 
how to maximize separation of aspects, components, and layers from each other 
to achieve the better design model and implementation of the operating system 
in terms of reusability, adaptability, extensibility, and reconfigurability. 



Streamlined PURE Systems 

(Danilo Beuche et. al.) Paper by Danilo Beuche, Reinhard Meyer, Wolfgang 
Schrder-Preikschat, Olaf Spinczyk, and Ute Spinczyk. Reinhard presented the 
paper [2] 

Embedded and especially deeply embedded systems tend to offer extremely lim- 
ited resources. Until now, this means a massive barrier for applying approved 
object-oriented design principles and abstractions to related operating systems. 
In this paper, the reasons are discussed why object orientation left on its own 
will burst the given limits. It is also suggested in brief how to improve the cre- 
ation of scalable object-oriented operating systems with upcoming design and 
implementation techniques from the software engineering community, providing 
streamlined solutions for actual environments. 
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3.4 Session “Performance” 

We had talks about how to exploit the hardware to boost performance or to 
achieve new services in a cheap way. 



26 Bit Selectors on IA32 

(Greg Law et. al.) Paper by Greg Law and Julie McCann. Greg presented 
the paper |7] 

The Intel 80386 (IA32) segmentation scheme is well suited to implementing 
memory protection in the new generation of finely-grained component-based 
operating systems. However, IA32 segments are identified by 14 bit selectors, 
giving a maximum of just 16,382 segments addressable at a time. This is contrary 
to the goal of fine-grained protection — a large system comprised of fine-grained 
components may require many times this number of components be addressable. 
Changing the IA32 specification to allow 32 bit selectors would be ideal, but 
is clearly impractical. This paper presented the strategy adopted in the Go! 
ccomponent-based operating systems, which is to virtualise selectors, using the 
IA32 ‘segment-descriptor table’ as a cache of a larger table, indexed by 26 bit 
selectors. 

A Cluster-Based Java NodeOS (JavaNOS) 

(Santiago Elbe et. al.) Paper by Santiago Eibe Garcia. Santiago presented 
the paper jS] 

An active network is more flexible than a traditional network architecture but at 
the expense of a performance degradation due to active code processing. Active 
Nodes must perform processing and therefore are slower than traditional ones. 
Thus, they are looking for a more powerful architecture where several nodes are 
connected with a local network and cooperate to provide the functionality of a 
single active node. They present a cluster-based NodeOS (Active Node Operating 
System). The architecture includes several Java NodeOS (JavaNOS) executing 
in JVMs (Java Virtual Machines) on different (clustered) nodes. 

4. Summary of the Discussions 

The workshop featured nice discussions both during the track devoted to discus- 
sion and during the coffee breaks. Even early in the workshop, participants could 
be found outdoors near a coffee machine discussing about operating systems. 

One of the discussion topics, which was not actually presented by any talk, 
was the usage of toolkits and ^kernels. The Oskit jl] was recognized as a nice 
toolkit for OS construction, although it was pointed out that it was huge, and 
that it could be perhaps replaced once the system was operational enough. 

One of the things we agreed upon is that the Oskit is nice whenever you 
do your stuff in the way the Utah guys think. Otherwise, pulling up one com- 
ponent forces you to include lots of different Oskit components that are dupli- 



Object-Orientation and Operating Systems 



39 



cating/fighting with your work. Therefore, you better replace it with you own 
implementation once everything works. 

Regarding //kernels and exokernels, it was agreed upon that they moved the 
complexity back to user space. The question of how many users are capable of 
handling such complexity arised. One of the papers, the “Umbrella” one, gave a 
nice way to hide again that complexity. The idea is that users that want to do 
small changes to the system should only change a small portion of code. Object 
orientation is of great help here. 

For some of the work, it was not clear how it was going to be implemented. 
In particular, there were a bunch of questions about what particular implemen- 
tation was going to be used for the Java NodeOS. We feel that designing an OS 
is one thing, but implementing it and getting it to work is really a big issue. 

Alan Dearie commented some experience with the grasshopper system and 
stated that although he had a bunch of papers about it, he found that it was 
not the way to go to get persistence. After some discussion, the agreement was 
that depending on the level where the job is done, it can be really much easier 
or harder. For instance, laptops can suspend the system and get “persistence” 
really cheaply. Persistence also raises the question of “persistent errors” . We felt 
that we should get back to simplicity. As Marc Shapiro showed, using application 
knowledge can simplify a lot the middleware, and make the difference between 
a complete framework that works poorly or does not work, and a framework for 
an application domain that works well and makes its users happy. 

We also felt that current hardware facilities are not well used. Besides the 
“suspension” facilities of laptops, another example was that current systems 
efectivelly make void the segmentation hardware, even though it can help a lot 
as Greg Law showed. 

Going back to the discussion of simplicity, the large set of interfaces that 
must be mastered to configure/reuse an 00 OS was also discussed. Both the 
Umbrella suggested by Alan Dearie, and the “Box abstraction” suggested by 
Francisco could be of help there. 

Automated tools that configure the system and remove unwanted code, or 
weave aspects into the system are also desired, and a couple of papers addressed 
this. 

We saw as a nice side-effect of the upcoming era of multiple interconnected 
dumb devices that you no longer have to maintain backward compatibility, and 
you can try better ideas. You can do so without worrying to break existing 
applications because there are no existing applications. 

5. Conclusion 

We all felt that we need systems more simple, that work and we agreed that we 
still have a long way to go using new technologies like aspect orientation, and 
today hardware facilities. 
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Abstract. This report gives an overview of the second ECOOP Work- 
shop on Formal Techniques for Java Programs. It explains the motivation 
for such a workshop and summarizes the presentations and discussions. 



1 Introduction 

The ECOOP 2000 workshop on Formal Techniques for Java Programs was held in 
Sophia Antipolis, France. It was a follow-up for last year’s ECOOP workshop on 
the same topic [JLMPH^ and the Formal Underpinnings of the Java Paradigm 
workshop held at OOPSLA ’98 [Eis98j . The workshop was organized by Sophia 
Drossopoulou (Imperial College, Great Britain), Susan Eisenbach (Imperial Col- 
lege, Great Britain), Bart Jacobs (University of Nijmegen, The Netherlands), 
Gary Leavens (Iowa State University, USA), Peter Muller (FernUniversitat Ha- 
gen, Germany), and Arnd Poetzsch-Heffter (FernUniversitat Hagen, Germany). 

There was lively interest in the workshop. Out of 27 submissions, the organiz- 
ers selected 21 papers for short presentations. Proceedings containing all selected 
papers are available as a technical report of the Computer Science Department of 
the FernUniversitat Hagen (see [DEJ~*~0d| L 44 people from universities, research 
labs, and industry attended the workshop. 



Motivation. Formal techniques can help to analyze programs, to precisely de- 
scribe program behavior, and to verify program properties. Applying such tech- 
niques to object-oriented technology is especially interesting because: 

— the 00-paradigm forms the basis for the software component industry with 
their need for certification techniques. 

— it is widely used for distributed and network programming. 

— the potential for reuse in 00-programming carries over to reusing specifica- 
tions and proofs. 

Such formal techniques are sound, only if based on a formalization of the lan- 
guage itself. 

Java is a good platform to bridge the gap between formal techniques and 
practical program development. It plays an important role in these areas and 
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is on the way to becoming a de facto standard because of its reasonably clear 
semantics and its standardized library. 

However, Java contains novel language features, which are not fully un- 
derstood yet. More importantly, Java supports a novel paradigm for program 
deployment, and improves interactivity, portability and manageability. This 
paradigm opens new possibilities for abuse and causes concern about security. 

Thus, work on formal techniques and tools for Java programming and formal 
underpinnings of Java complement each other. This workshop aims to bring 
together people working in these areas, in particular on the following topics: 

— interface specification languages 

— specification of software components and library packages 

— specification techniques, in particular for distributed applications 

— modularity and reuse of specifications and proofs 
~ verification technology and logics 

— automated checking of program properties 

— Java language semantics 

— Java environment issues 

— Java virtual machine 

~ dynamic linking and loading, security 

Applying formal techniques to a special programming language and its programs 
raises two questions: Are the formal techniques mature enough to deal with the 
language? Is the language an appropriate candidate to be used as a target for 
formal techniques? The workshop emphasized the first question. 



Structure of Workshop and Report. The one-day workshop consisted of a 
technical part during the day and a workshop dinner in the evening. 

The technical part was structured into five sessions. Each session consisted of 
four to five short presentations on closely related topics, followed by a discussion 
of the presented work and related questions. There were sessions on “Language 
Semantics” , “Bytecode Verification and Type Analysis” , “Verification I” , “Spec- 
ification and Verification II”, and “Language Design and Implementation”. The 
workshop dinner was an informal event that allowed the participants to exchange 
ideas, discuss open questions, and establish collaborations. 

The rest of this report is structured as follows: Sections 2 to 6 summarize 
the presentations and discussions of the five technical sessions of the workshop. 
The conclusions are contained in Section 7. A list of participants with email 
addresses can be found in the Appendix. 



2 Language Semantics 



The first session was mainly focused on semantics of the concurrency features 
of Java. There were four talks. The first was given by Marjorie Russo on the 
current state of the Sophia Antipolis Java semantics project. The second talk. 
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presented by Pietro Cenciarelli gave an event structure semantics of threads and 
synchronization. The third talk, given by Davide Ancona, was the odd one out 
as it was about exceptions. The last talk was by Vishnu Kotrajaras who clarified 
repercussions of the threads model of Java. 

Marjorie Russo started the session and the workshop off with a presentation 
of her joint work with Isabelle Attali, Dennis Caromel, and H. Nilsson on the 
current state of their work at INRIA, Sophia Antipolis. The talk was entitled 
’’From Executable Formal Specification to Java Property Verification”. They 
take their formal semantics (written within their generic Centaur system), which 
is executable, and use these to both derive a program development environment 
and secondly to prove properties about their semantics. 

Their semantics are represented as an abstract syntax tree and are in a Nat- 
ural Semantics style. Concurrency is simulated with a deterministic interleaving 
of threads, the details of which Russo described in her talk. We were shown 
how the environment provided a graphical animation during program execution 
using annotations of the semantics. Then Russo discussed how to verify pro- 
gram properties using their semantics. Her example was about synchronization 
of threads. 

Further details about the this work can be found at |ACNP.0T)llP,us()0] . 

Pietro Cenciarelli of the University of Rome presented his work on ’’Event 
Structures for Java”. This work was motivated by the lack of a semantics for 
concurrent object-oriented languages like Java. The lack exists because although 
parallel processes in a process calculi make a composite process, parallel running 
objects do not make a composite object. The semantics that do exist for Java 
with threads lack a natural notion of contextual equivalence. Cenciarelli pre- 
sented a semantics of a subset of Java with threads and synchronization, based 
on Winskel’s event structures that is suitable for studying notions of equivalence 
of Java programs. 

Cenciarelli discusses program equivalences, where two programs are equiv- 
alent only if they denote the same event structure. Unfortunately, this is not 
enough to prove commutativity of assignment, that is that one thread cannot 
observe the order in which another thread performs assignments to shared vari- 
ables. 

Further details about the this work can be found at [CenOOal ICenOOb] . 

Davide Ancona presented his joint work with Giovanni Lagorio and Elena 
Zucca at the University of Genova on ”A Core Calculus for Java Exceptions”. 
To better understand the semantics of Java exception handling they stripped 
Java down to a simple calculus called CJE (Calculus for Java Exceptions). CJE 
is similar to Featherweight Java, it contains only those features needed to un- 
derstand exceptions. CJE is functional. 

After presenting the CJE and its reduction semantics we were shown two 
provably equivalent type systems and subject reduction. They show that com- 
patibility checks for throws clauses are complex. Their minimal type system 
helps to understand Java exception handling. Finally they suggest a small lan- 
guage restriction (to require a class that implements an interface to implement 
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all its methods) that would simplify showing static correctness without seriously 
restricting programmers. 

Further details about the this work can be found at |ALZ00l lAncOO] . 

The last talk of the session was given by Vishnu Kotrajaras of Imperial 
College who presented his work with Susan Eisenbach on ”A demonstration of 
data inconsistency in the Java memory model”, which describes how threads 
behave in Java. When synchronization is used the behavior is as expected, but 
synchronization carries a very heavy timing overhead. Java also has volatile 
declarations which appear to be a lighter weight way of guaranteeing sensible 
behavior but this work shows how limited volatile declarations are. 

From the Java Language Specification[GJS96] it appears that using volatile 
declarations it is possible that data used will not necessarily be the latest avail- 
able data. For example a thread might not load the latest data item before using 
it. Kotrajaras ran tests and found that Java compilers do behave as stated in the 
language specification and then showed us applets that simulated this behavior 

Further details about the this work can be found at |KE00L IKotOO] . 

3 Bytecode Verification and Type Analysis 

This session was about issues related to bytecode verification and class loading. 
The general goal of this session was the presentation and discussion of formal 
techniques that help to improve the specification of the Java Virtual Machine and 
the class loading process. Aspects of bytecode verification were of special interest. 
The session contained four presentations (cf. |KN001 ICGOOl lBD,T~*~00l IWraOOj ) 
each of which highlighted a certain aspect of type analysis for dynamically loaded 
bytecode programs. In the following paragraphs we provide a short introduction 
of these aspects and sketch the presented contributions. 

Bytecode verification is a technique to check whether a piece of bytecode 
is type sound. Since storage locations are not explicitly typed in the bytecode, 
it first has to reconstruct type information. Based on this information it per- 
forms type checking. As the reconstruction of the type information takes time 
and space, resource-bounded implementations of the Java Virtual Machine on 
smart cards do not provide bytecode verification. They do not allow dynamic 
loading at all or use cryptographic techniques to rely on off-card verification. To 
enable on-card verification, Eva and Kristoffer Rose |I!R,98J developed a sparse 
annotation of bytecode with type information to drastically simplify type recon- 
struction. This way, on-card verification essentially becomes a linear type check. 
This technique is called lightweight bytecode verification. 

Gerwin Klein (with coauthor Tobias Nipkow, both TU Munich) presented 
a formal proof that lightweight bytecode verification is sound and complete. 
Roughly speaking, soundness means that the lightweight verifier should only 
accept an annotated pieces of code if the fullweight verifier accepts the stripped 
version. Completeness means that the lightweight verifier should accept every 
piece of code that is annotated with the types reconstructed by the fullweight 
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verifier if the fullweight verifier accepts the code. The formalization of lightweight 
bytecode verification and the proof was done in Isabelle/HOL. It was based 
on an existing formalization of the JVM and used a variant of the annotation 
techniques of |RR98| . 



Type analysis in general and bytecode verification in particular needs a pre- 
cisely defined type system. Especially, it has to be crystal clear when two given 
types should be considered identical. Usually, types can be uniquely identified by 
their names. For instance, in Java each type has a so-called fully qualified name, 
FQN for short. However, in the Java Virtual Machine (JVM) two types with the 
same FQN may correspond to different class implementations. The reason for 
that is that different class loaders can load different classes for the same FQN. 
That is why a class in the JVM specification |LY99j is identified by its FQN and 
its defining loader. 

In his presentation, Alessandro Coglio (with coauthor Allen Goldberg, both 
Kestrel Institute) described a problem caused by unprecise treatment of type 
identity: For some operations the bytecode verifier only used the FQN to deter- 
mine type identity and not information about the defining loader. The problem 
affects bytecode verification and can lead to undetected flaws in the bytecode. 
The presentation described a scenario for such errors. It turned out that these 
errors really show up in versions of the JDK. This particular problem can be 
fixed by using information about the applied class loader. As a more general 
approach, Coglio proposed to a solution that more clearly separates bytecode 
verification and class loading. The idea is to generate refined loading constraints 
during byte code verification. In the discussion, it was pointed out that this 
technique also simplifies formal verification of bytecode verification. 



Formal, machine-supported analysis presupposes an appropriate formaliza- 
tion of the objects and properties of interest. In her presentation. Line Jakubiec 
reported on the formalization of the Java Card Virtual Machine in the language 
of the Coq prover (with coauthors Gilles Barthe, Guillaume Dufay, Bernard Ser- 
pette, Simao Sousa, and Shen-Wei Yu, all INRIA Sophia- Antipolis) . This work 
is part of a long-term project to establish a formal verification framework that 
allows to prove safety properties of the JCVM on the platform level as well as 
on the level of individual programs (see http://www-sop.inria.fr/oasis/SJava). 

The presentation concentrated on two aspects: an operational small-step se- 
mantics of Java Card programs and the description of a tool that translates CAP 
files into their Coq representation. A CAP file is the result of bytecode verifying 
and optimizing a class file for the JCVM. The operational semantics comprises 
a formalization of programs for the JCVM, of the memory model of the JCVM, 
and of semantics defining the execution steps on the machine. The specification 
captures the firewall mechanisms and shareable interfaces. The operational se- 
mantics is given in a functional style that allows to execute the specification, 
thereby simulating JCVM executions. The discussion did not succeed in clarify- 
ing further distinction to comparable formalizations. 
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Bytecode verification is used to establish type safety at load time. This is 
necessary in addition to the checks performed by the compiler because bytecodes 
for classes may not match due to deliberate modification of the bytecode or 
versioning problems. Consider a program with class A that uses a library class 
C. During compilation type safety of A is checked relative to C. After a new 
version of C is installed the bytecodes of A and C may no longer match. A 
change to a class is called binary compatible if the compiled version of the class 
can be used in all places where the original version could be used. 

In his presentation, David Wragg introduced two formal models of linking 
suitable for reasoning about binary compatibility in Java and other languages. 
The first model is based on so-called fragment systems and enables to investigate 
the high-level laws and properties of sets of binary program fragments. The 
second model provides an abstract technique to formulate requirements and 
provisions of fragments. It is still language independent. 



4 Verification I 

There were four talks in the session on Verification |BriOOI ICNOOL ISkeOOL IOheOOa| . 
The first one by Pascal Brisset from France Telecom R&D involved a case study 
in Java software verification, focusing on the correctness of a checkConnect () 
method for a security manager. Such a method throws a SecurityException if 
a certain security policy is violated. A standard pattern, used in many places in 
the Java API and in applications is to invoke this method before some critical 
code can be executed. The challenge is to prove that attack scenarios are ex- 
cluded with this pattern. This involves reasoning about various aspects of Java: 
field access, (static) initialization, exposure, etc. Brisset is combining several ver- 
ification techniques (model checking, Hoare logic for byte code) in order to try 
to formally establish correctness. 

Then, David Naumann from the Stevens Institute in New Jersey (with coau- 
thor Cavalcanti from Recife in Brazil) talked about simulation and class re- 
finement for Java-like languages. He uses the standard algorithmic refinement 
relation in order to define refinement between classes, by applying it to suitable 
programs from these classes. This should allow correctness preserving replace- 
ment of one class by another. This work is applied to language with some aspects 
from Java (inheritance & dynamic binding, visibility control, recursion, but no 
pointers or concurrency) . The semantics of commands is given by predicate trans- 
formers. The authors claim to be close to proving that forward simulation can 
be used as proof technique for their refinement. 

Sotiris Skevoulis from Pace University, New York, talked about the techniques 
underlying his research prototype tool for static analysis of Java programs. In 
its current form this tool concentrates on detecting illegal dereference and array 
bound violations, which might arise during program execution. It uses a special 
purpose theorem prover to discharge the generated proof obligations, arising 
within a weakest precondition semantics. 
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This tool is not meant to detect all possible errors, but to find the majority 
of them (of a special, restricted kind). As such it is explicitly developed for 
the use of light-weight formal methods. One of its most salient features is that a 
programmer should be able to use this tool without having to write specifications. 
This point gave rise to some discussion, with various members of the audience 
asking for a comparison with the successful ESC/ Java project at Compac£]- 
Although the two projects are similar in their aims and approaches, Skevoulis 
insisted on the key aspect of absence of need for specifications for his tool. (Aside: 
also at Compaq SRC experiments are being done with static checking without 
specifications provided by the user.) It is still too early to tell what the impact 
of these developments will be. 

Finally, David von Oheimb reported on his work on the axiomatic semantics 
of Java, carried out within the Bali project in Munich [lOheOObj . It involves the 
language Java^*®^*, which is a nearly full subset of sequential Java. Earlier a 
deep embedding of Java^*®^* into the higher order logic of the theorem prover 
Isabelle has been developed, together with an operational semantics. Von Ohe- 
imb described a Hoare logic for Java^*®^*, which he has proven (in Isabelle) to 
be both sound and complete (w.r.t. the operational semantics). The logic covers 
challenging features like exception handling, static initialization of classes and 
dynamic binding of methods. The soundness and completeness proofs rely on the 
type safety property (dynamic types of expressions are subtypes of their static, 
declared types), which was already proven for Java^*®^*. 

At the end of this presentation there were questions about the relations 
between the three currently available tool-supported Hoare logics for Java. Here 
is a brief summary. 

— There is a tool “Jive” which supports Hoare logic for a subset of Java (with- 
out exceptions) |PHM99| . It allows syntax-based reasoning about concrete 
programs, and sends the proof obligations that arise to PVS. 

— A Hoare logic with different output modes for abrupt termination is defined 
in [HJ00| . It is used for semantics-based reasoning about individual Java 
programs, using the translation into PVS provided by the “LOOP” tool. 

— In contrast to these two approaches, the presented work of von Oheimb is 
meta-theoretical, dealing with Java programs in general. 



5 Specification and Verification II 

This session of the workshop contained four papers IBecOOl lAIPHOOl IJNakOOl 
IBPJOOl and two short presentations by Arnd Poetzsch-Heffter and Gary Leavens. 
The papers are discussed below. 

Ataru T. Nakagawa’s paper [NakOOJ had as its goal making distributed com- 
ponent search more practical and secure. Component search is done in two steps. 
First, signature matching (a la Zaremski and Wing IMZWfi?] ! is done to find a 

See the URL http://www.research.digital.com/SRC/esc/Esc.html 
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set of components with appropriate types. Then these component are checked 
to see if they have the appropriate behavioral properties. 

Specifications of the desired properties are given in first-order logic with 
equality. However, component specifications are stated in a restricted form of 
the CafeOBJ language [DF99J . CafeOBJ uses a variant of equational logic that 
supports conditional equations and hidden types. 

Nakagawa described an implementation that combines model checking and 
automatic theorem proving. Automatic theorem proving, in the form of context 
induction and coinduction, is used to find observationally equivalent elements. 
A model checking technique is used to prove invariants. Some preliminary case 
studies have been done, mainly protocol specifications and proofs of safety prop- 
erties. Only small component searches have been done so far. All of these case 
studies took on the order of seconds or minutes to execute. 

Joachim van den Berg, Erik Poll, and Bart Jacobs’s paper |BPJ00j had as its 
goal giving a formal semantics to JML. JML [ILBROOj is a behavioral interface 
specification language for Java. Following Eiffel |Mey97| , it uses Java expressions 
in assertions. These expressions present a semantic problem, because, besides 
terminating normally, they might go into infinite loops or throw exceptions. 
The semantics must transform these expressions into ordinary two- valued logic. 
(A three-valued logic is undesirable because it does not match current theorem 
proving technology.) 

The proposed solution to this problem builds on authors’ earlier work 
jJBH~*~98) . This work already has a semantics of Java expressions. The paper 
extends the semantics of these expressions to deal with JML’s extensions to 
Java. More important is the recognition that different translations are needed 
for pre- and postconditions. In a postcondition, a predicate that throws an ex- 
ception is turned into “false” . However, this is not appropriate for preconditions. 
The problem is that a precondition provides an assumption that can be used in 
verifying the implementation of a method. If exceptions in preconditions mean 
the precondition is “false” , then these assumptions are too strong, making the 
proof of correctness of an implementation trivial. Because of this, exceptions in 
preconditions are turned into “true” . 

Some discussion of this proposal took place during the workshop. Some par- 
ticipants (notably John Boyland), advocated using the standard Java semantics 
for expressions, as much as possible. However, this would essentially require 
using a three-valued logic. Another proposal was to require specifiers to make 
both pre- and postconditions “protective” |LW98j ; however, checking this seems 
to require theorem proving. 

Bernhard Beckert’s paper | BecOO| had as its goal the integration of existing 
tools and methods for object-oriented design (such as Together J, UML, and 
OCL) with the technology of formal software verification. The target language 
is Java Card, which is a subset of Java that lacks some complications, such as 
threads and dynamic loading. 

The approach taken in the KeY project, in which Beckert is participating, 
is to give a semantics to the Java Card language using dynamic logic [KT90j . 
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Beckert gave various proof rules for the Java Card language. These show how 
deduction in dynamic logic is [BecOOL p. 112] “based on symbolic program exe- 
cution and simple transformations and is, thus, close to a programmer’s under- 
standing of Java Card.” Beckert discussed various modeling problems in the 
semantics, including side effects, exception handling, and object initialization. 

This is an interesting contrast to the work on JML presented just before it. 
Instead of making the semantics of assertions deal with side effects and excep- 
tions, specifiers can say how to deal with them directly. This is done by using 
Java programs within dynamic logic formulas. 

Peter Muller and Arnd Poetzsch-Heffter’s paper |MPH00j had as its goal 
controlling representation exposure. Representation exposure occurs when refer- 
ences to mutable objects within a component are passed outside its boundary. 
Clients of the component can then manipulate the representation in unexpected 
ways. 

The approach taken to solving this problem is to define a new type system. 
In this type system each component owns a “universe” , which is a collection of 
objects. These objects may refer to each other, but only the objects that are part 
of the interface of a component (owner objects), may refer to objects within the 
universe. Other objects that are outside the universe cannot reference objects 
inside it. 

The universe type system has two advantages over related work. First it 
introduces read-only reference types; these are useful in the implementation of 
container objects, iterators, and binary methods. Second, one may downcast a 
read-only reference to a normal reference, with a run-time check (as in a Java 
cast). This seems to be helpful when extracting objects from containers in Java. 
A proof of type safety and a “representation containment property” has been 
done. 

6 Language Design and Implementation 

Mel O’ Cinneide and Pat Nixon | ONOO| reported on on composite refactorings 
for Java. Despite the recent interest in refactoring, little work has been done on 
tool support for refactoring or on the demonstration of preservation of program 
behavior by refactoring. They proposed a method for the development of com- 
posite refactorings for Java programs in such a way that a rigorous demonstra- 
tion of behavior preservation is possible. Sophisticated program transformations 
may be built by composing primitive refactorings using sequencing, iteration 
and conditional constructs. Each primitive refactoring has a precondition and 
a postcondition. When applied to a program for which the precondition holds, 
the resulting transformed program exhibits the same behavior as the original, 
and the postcondition holds for this program. They described a technique that, 
given a composition of refactorings, computes whether it is itself a valid refac- 
toring, and what its pre- and postconditions are. They applied these techniques 
to develop a tool that can, with guidance from the user, apply a suite of design 
patterns to a Java program in a behavior-preserving way. 
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Eva Rose and Kristoffer Rose [RHROOJ suggested the integration of a ded- 
icated read-only field access into the Java type system. The advantage is that 
“getter” methods can be eliminated, and allow for 1) static look-up as opposed 
to dynamic dispatch, 2) avoidance of the space for the code of the getter method, 
3) avoidance of denial of service attacks on field access, 4) discovery of access 
protection violating through the byte code verifier. They describe this through 
an extension of the byte code verifier. 

There were heated discussions as to the merits of this suggestion. On the 
one hand it was considered elegant and concise, on the other hand, people ad- 
vocated that fields should not be visible to the clients of the classes anyway (as 
in Smalltalk), and field access from outside the object is bad practice. An opti- 
mizing implementation should transform the getter methods into fast accesses. 

Eun-Sun Cho and Kwangkeum Yi | CY00| suggested an escaping analysis for 
Java Programs, to identify stack-allocatable objects. This analysis considers an 
object escaping if it is used after the deactivation of the method that created 
it. For each object this analysis records the interprocedural movement of the 
method of its creation. An object is considered escaping the method that created 
it, if the method of its creation has been already deactivated. Our approach is 
different from prior works, in that special cares of non-local variables need not 
be taken. This enables us to handle some cases that are missed in the previous 
approach. 

There was a short debate on the the limitations of abstract interpretation as 
well as on the availability of experimental results. 

Davide Ancona, Elena Zucca, and Sophia Drossopoulou [lAZDOO] commented 
on the incorporation of overloading into the language Java. Overloading offers the 
possibility to define defining many functions with the same name and different 
argument types. In the case of languages with a subtyping relation, notably 
object-oriented languages, overloading resolution is not trivial, since for a given 
call there can be many functions (methods in this case) whose arguments type 
matches the call. Hence, the language must specify a precise rule for selecting 
one among these applicable methods. The Java rule selects the ’’most specific” 
method, if any (otherwise the call is ambiguous), where a method declared in 
a class c with arguments type a is more specific than another declared in a 
class d with arguments type a! if both a < and c < d where ^ is the 
subtyping relation. They propose an alternative rule which does not take into 
account the class where the method was declared, arguing that this is both 
in contradiction w.r.t. a natural understanding of inheritance semantics and 
unnecessarily restrictive. The latter means that there are some ambiguous calls 
for which no execution would give different results for the different possible 
choices. We show a simple formalization of the Java and the alternative rule and 
formally prove that the latter is a conservative extension of the former, that is, 
selects the same method when Java does, but gives meaning to more calls than 
Java does. 

Last, Susan Eisenbach and Tatyana Valkevych presented their Web based 
Java test suite which allows people to submit their test programs and test 
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them against several Java compilers. It is possible to select language features 
to tested, or test all test programs. The aim is both to test compilers’ adherence 
to the language semantics, and also clarifications of people’s misunderstand- 
ing about the language semantics. The test suite can be found at http://www- 
dse.doc.ic.ac.uk/projects/slurp/pubs.html, and the authors invited the audience 
to submit test programs. 

There was a heated discussion as to the format of these programs, acknowl- 
edgment of the authorship, and copyright. 

7 Conclusions 

The interest in the workshop, and the lively discussions at the workshop itself 
show that many researchers are applying their techniques to either the Java 
language or to programs written in Java. Although Java is a rather complex 
language, having a common programming language makes it significantly easier 
to compare and discuss different approaches and techniques, and stimulates co- 
operations. This synergy was evident at the workshop, which helped make it a 
highly successful event that was appreciated by the participants. 
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WCOP 2000, held in conjunction with ECOOP 2000 in Sophia Antipolis, France, 
was the fifth workshop in the successful series of workshops on component- 
oriented programming. The previous workshops were held in conjunction with 
the respective ECOOP conferences in Linz, Austria, Jyvaskyla, Finland, Brus- 
sels, Belgium and Lisbon, Portugal. WCOP96 had focussed on the principal idea 
of software components and worked towards definitions of terms. In particular, a 
high-level definition of what a software component is was formulated. WCOP97 
concentrated on compositional aspects, architecture and gluing, substitutabil- 
ity, interface evolution, and non-functional requirements. WCOP98 had a closer 
look at issues arising in industrial practice and developed a major focus on the 
issues of adaptation. WCOP’99 moved on to address issues of component frame- 
works, structured architecture, and some bigger systems built using components 
frameworks. The topics for WCOP 2000 focussed on component composition, 
validation and refinement and the use of component technology in the software 
industry. 

WCOP 2000 had been announced as follows: 

WCOP 2000 seeks position papers on the important field of compo- 
nent-oriented programming (COP). WCOP 2000 is the fifth event in a 
series of highly successful workshops, which took place in conjunction 
with every ECOOP since 1996. 

COP has been described as the natural extension of object-oriented 
programming to the realm of independently extensible systems. Sev- 
eral important approaches have emerged over the recent years, including 
CORBA, COM, JavaBeans, and more recently COM-b, EJB, and CCM. 
After WCOP’96 focused on the fundamental terminology of COP, the 
subsequent workshops expanded into the many related facets of com- 
ponent software. WCOP 2000 shall emphasis architectural design and 
construction of component-based systems beyond ad-hoc reuse of unre- 
lated components. 

To enable lively and productive discussions, the workshop will be lim- 
ited to 25 participants. Depending on the submitted position papers, the 

* The workshop papers are available at http://www.cs.rug.nl/~bosch/WCOP2000. 
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workshop will be organized into three or four subsequent mini-sessions, 
each initiated by a presentation of two or three selected positions and fol- 
lowed by discussions. Instead of splitting the workshop into task forces, 
it is intended to provoke lively discussion by preparing lists of critical 
questions and some, perhaps provocative, statements (to be used on de- 
mand) . 

Position papers will be formally reviewed, each by at least two inde- 
pendent reviewers. As an incentive for submission of high quality state- 
ments, the best position statements will be combined with transcripts of 
workshop results and published. 

Last year’s WCOP’99 report observed: “One interesting trend that we have 
identified over the years is a change in focus. Whereas the first workshops aimed 
at the individual components, especially during the last event there was a clear 
consensus that the focus should be on the component architecture, i.e. the co- 
operation between components. In particular, not the component-’ wiring’ stan- 
dards, such as CORE A, COM and JavaBeans, but rather the system design level 
issues, such as software architectures and component frameworks.” Interestingly, 
this trend was maintained for WCOP 2000. Even the more formal work on val- 
idation and refinement focussed on the composition of components, rather than 
individual components. 

25 papers from more than 10 countries were submitted to the workshop 
and formally reviewed. Thirteen papers were accepted for presentation at the 
workshop and publication in the proceedings. About 40 participants from around 
the world participated in the workshop. 

The workshop was organized into three morning sessions with presentations, 
one afternoon breakout session with six focus groups, and one final afternoon 
session gathering reports form the breakout session and discussing future di- 
rection. The opening and closing sessions were run together with an associated 
workshop on pervasive component systems, which allowed for interesting cross 
fertilization. 



1 Presentations 

This section summarizes briefly the contributions of the thirteen presenters, as 
presented in three sessions, i.e. validation & refinement, component composition 
and industrial approaches. 



1.1 Validation and Refinement 

The first session consisted of four papers. The first paper, by Eddy Truyen, Bo 
Norregaard Jorgensen, Wouter Joosen and Pierre Verbaeten, addressed the issue 
of interaction refinement in middleware. The authors propose to use a reflective 
approach to allow for dynamic reorganization of, among others, object request 
brokers to refine interaction at run-time. The authors apply this approach to 
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dynamically integrate new services that support non- functional aspects, such as 
security, transactions and real-time behaviour. 

The second paper of Joao Costa Seco and Luis Caires presented the compo- 
sition language ComponentJ, to which parametric typing was added recently. In 
Component J, a component can state which services it requires to be plugged in. 
In the respective requires clauses component types are used. Similarly, provides 
clauses state the types implemented by a particular component instance. Actual 
instances can now be connected using the plug-into clause. Of course, instances 
plugged together this way have to adhere the type constraints formulated by the 
requires and provides clauses. ComponentJ also supports subtyping and bound 
parametric polymorphism for component types. 

Another approach of separating composition from implementation was taken 
by the authors of the third paper, Kris De Voider, Johan Fabry, and Roel Wuyts. 
Their proposal is to deploy logic programming to describe properties objects 
must have to be composable with each other. At compile time the logic program 
is ran and matches are made. With the help of this, for instance, visitor objects 
can be implemented much more independent of the structures to be iterated over 
by the visitor. Such patterns, cutting across several classes, can be expressed in 
isolation rather than smeared across all involved classes. 

The fourth and last paper of this session was presented by Chris Wild and 
co-authored by Robert Cherinka, John Ricci and Michael Overstreet. The au- 
thors pointed out that with increasing information hiding within components 
integration tests of mission critical systems become more and more difficult. 
Whereas of-the-shelf components can considerably speed up application devel- 
opment in the beginning, extra effort needs to be put into testing and validating 
the composed system if it is going to be mission critical. Internal states of ac- 
quired components cannot easily be observed and components cannot easily be 
provoked to exhibit behavior that might be required to put other components 
into a stress test. The authors hence propose to open up components for these 
purposes in a controlled way. Additional testing interfaces can be provided, for 
instance to observe internal state, and testing instructions should be made part 
of a component’s description. Such requirements go beyond today’s components. 

1.2 Component Composition 

The second session consisted of six papers, covering various facets of compo- 
nent composition. The first paper, presented by Oliver Stiemerling and Pascal 
Costanza, focused on object identity and dynamic recomposition of components. 
They described their prototype system Evolve, which presents 3D-views of the 
dynamic configuration of distributed systems. Comparing Evolve to a precision 
instrument for open-heart surgery, they explained how it can be used to change 
system configurations at run-time. Evolve models components with explicit in 
and out connections and manifests its effects on a system in terms of transi- 
tions. Under a configuration transition, old and new components can coexist 
for a while. This leads to potential overlaps in state. Evolve has mechanisms to 
deal with the consistent maintenance of object identity under such transitions. 
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However, the necessary transfer of state remains an open issue. They described 
how the new can act as a wrapper of the old component to handle such state 
transfer in certain cases. 

The second paper introduced an approach to the declarative description of 
component models in an attempt to support software composition generically; it 
was presented by Marie Jose Presso. Their goal is to devise a composition model 
that is independent of particular builder tools and their approach is to use logic 
meta-programming. Composition is expressed using facts and validity checking 
using queries. The resulting descriptions they found are a powerful tool for code 
generation; a result that they validated with a JavaBeans-based prototype. 

The third paper, presented by Sanjiva Weerawarana (co-authors are Fran- 
cisco Curbera and Matthew J. Duftler), covered another approach to composition 
languages. Besides presenting the right composition operators and an opportu- 
nity to place required glue code, they claim that, to be successful, composition 
languages must fit into current development realities. Hence, they do not intro- 
duce a new component model. In their present work they use JavaBeans, but 
they wish to extend to other models (COM, CCM) with an aim to mix and com- 
pose across multiple models. Further, they emphasized that the approach must 
not interfere with object-oriented programming, thus requiring a separate com- 
position structure. They propose that such an approach leads to a new market 
of composers that don’t require OOP training. (‘Scripting languages are your 
friend.’) Their approach rests on two pillars: BML (Bean Markup Language) 
and BSC (Bean Scripting Component). BML is an XML-based composition lan- 
guage that can be interpreted or compiled. A BSC is a component encapsulation 
of a composition script; when combining BML and BSCs, their approach gets 
recursive. In the future, they wish to extend their work to support testing and 
validation. The required component description language is an open issue. 

The fourth paper on abstract plug-in components with behavior was pre- 
sented by P.J. ’t Hoen (co-author L.P.J. Groenewegen) . Focusing on packages 
as the basis of their approach, they extend the idea of packaging classes to that 
of packaging objects. Such packages of objects help to perform instance-level 
composition. In a recursive step, they view packages themselves again as classes. 
They made this approach concrete in their SOCCA language. 

The fifth paper discussed an architecture to support dynamic composition 
of service components and was presented by Bernard Pagurek (co-author David 
Mennie). Their basic scenario are networked services composed using the Facade 
pattern. Where performance matters, such a composition can be integrated, cre- 
ating a stand-alone interpreted service. Their architecture aims to support exist- 
ing technology (Jini, JavaBeans) and uses an XML-based composition language, 
augmented by a repository of available components. They created a Component 
Manager service for Jini that oversees all aspects of dynamic composition. An 
issue is to how to avoid undesired feature interaction. The Component Manager 
uses XML-encoded service specifications-avoiding unwanted interaction is hard, 
since the composition is done on-line. 
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The sixth paper presented by Dietrich Birngruber (co-author Markus Hof) 
outlined interactive decision spots for JavaBeans composition. Their observation 
is that the same beans are typically wired in very similar ways again and again. 
Thus, they propose that bean programmers provide typical wiring scenarios, 
leaving only specific decision spots open. The net effect would be to deliver a 
customizable wizzard with a bean. 

1.3 Industrial Approaches 

The third session consisted of four papers, covering software product lines, config- 
uration management, non-programmer use of components and the use of agents 
as components. 

The first paper was presented by Denis Conan (co-authors are Michel Coriat 
and Nicolas Farcet). The focus of the paper was the development of software 
components in the context of software product lines. The authors describe a 
meta-model for software component development covering three activities, i.e. 
design, implemenation and delivery. The meta-model allows one to express design 
transformations, such as component composition and splittin, abstraction and 
refinement. 

The second paper addressed the configuration management of components 
and was presented by Ivica Crnkovic (co-author Magnus Larsson). The authors 
start out with discussing the problem of component selection, i.e. when con- 
structing a component-based system, how does one select components that pro- 
vide the required functionality and quality attributes. Since components typi- 
cally are available as binary units, the prefered approach would be to associate 
information with the binary representation. However, this is not feasible for ex- 
ternally developed components, requiring the component user to extensively test 
these components in order to understand their properties. The authors propose 
the use of software configuration management principles to address these issues. 

Erlend Stav addressed a problem little discussed in the component-oriented 
program community: the construction of software systems by non-programmers 
using a component-based environment. The approach taken is to make use of 
visual means for component composition. This basically defines a visual pro- 
gramming language with a rather limited vocabulary for building systems. The 
presentation was refreshing in that most approaches to component instantiation 
are concerned with providing the component user, who is expected to be an 
expert, with as much configurability as possible. The work presented by Stav, 
however, was interested in limiting number of variation points as much as pos- 
sible, while maintaining freedom for the user. 

The final presentation in this session was presented by Jean-Guy Schneider 
(co-authors are Oscar Nierstrasz and Franz Achermann) . The authors presented 
the notion of agents as a type of component. Their motto was ’’agents every- 
where, all the time” . The authors identify that computing is moving towards per- 
vasive, wireless, spontaneously networked computing devices and their assump- 
tion is that these devices and the services that they provide will be represented 
as agents. In the paper, three open issues are discussed, related to development. 
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operation and validation. First, what paradigms and approaches can be used to 
develop the aforementioned agents. Second, what identification and interaction 
models should be used for these agents. Finally, what validation approaches are 
available that allow us to reason about the properties of such emergent networks. 
These issues are discussed Piccola, a small composition language. 

2 Breakout Session 

The following six breakout groups were formed: 

1. Components and architectures. 

2. Embedded and pervasive systems. 

3. Component evolution. 

4. Scalability and granularity. 

5. Variability. 

6. Degrees of encapsulation. 

Most of the groups had between five and twelve members, all with a desig- 
nated scribe and a designated moderator. The following subsections summarize 
each groups findings. 

2.1 Components and Architectures 

This break-out group identified early that its participants had two distinct inter- 
pretations of the title. One group interpreted it as component architectures and 
was interested in the interaction between components. The other group inter- 
preted it as the relation between the software architecture and the architectural 
components that it specified and the software components that provide the im- 
plementation for architectural components. The group decided to discuss both 
topics. For component architectures, the discussion focussed on the unification 
of type systems and other aspects of component-based systems. For instance, 
an event generated by one component may be interpreted rather differently by 
the component(s) that received the event. Since components are developed by 
different parties, one cannot assume that these share semantics for synctactic 
types and events. 

The second interpretation was discussed as well. The main topics during the 
discussion included the relation between quality attributes and requirements at 
the architecture and those at the level of the individual components. A second 
topic that was discussed was variability. Variation points can be introduced and 
bound at the level of the architecture, the components and inside components. 
Preferably, one would prefer freedom in selecting the optimal level for introducing 
the variation point, which is a challenge when using components. The third 
topic was concerned with dynamic software architectures, i.e. systems that can 
dynamically reorganize themselves in response to changes in its context or to 
incorporate new functionality that becomes available. When the architecture of 
a software system changes dynamically, how do components manage this? 
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Finally, the difference in interpretation of the title of the breakout group 
led to a terminological discussion. Interestingly, the participants reported that, 
after the discussion, they were no longer certain about the difference between 
concepts such as architecture, framework, component and composition! 



2.2 Embedded and Pervasive Systems 

The breakout group was primarily interested in the resource constraints present 
in embedded and pervasive systems and the effect on component-based software 
engineering. The group started with asking among themselves why they were 
interested in using components even in these types of software systems. The 
answers that they found were: reduced cost, improved reuse, reduced complexity, 
improved maintainability and improved customizability. Thus, good arguments 
exist for why to use components in the embedded domain. 

Once this was cleared up, the group focussed on three specific issues that 
they considered to be most central. First, the specification of constraints, such 
as quality of service, memory consumption and energy consumption, is not nec- 
essarily relevant for general purpose components, but crucial for components in 
an embedded context. A component that provides the required functionality, but 
does not satisfy the quality requirements, such as the ones mentioned above, is 
still useless for the system at hand. The second issue was concerned with the 
run-time overhead of virtually all component models. Due to additional levels 
of indirection and the availability of functionality not necessarily required in all 
types of systems, component models impose an overhead that needs to be out- 
weighed by the advantages. Finally, the break-out group participants discussed 
the immaturity of the infrastructure in embedded systems. 

2.3 Component Evolution 

Component evolution was first decomposed into two types, i.e. anticipated and 
unanticipated evolution. When the organization using the components also owns 
them, the evolution is generally anticipated. Otherwise, components are typically 
black-box and evolution is often unanticipated. 

The breakout group continued to identify the driving forces for component 
evolution. Three forces were identified, i.e. environment changes (what the com- 
ponent requires), requirement changes (what it provides) and, finally, changes 
to the management interface. 

Finally, evolution of external, black-box components was discussed and it was 
concluded that wrappers, despite their disadvantages, currently are the primary 
means for achieving evolution. 



2.4 Scalability and Granularity 

The core issue in this breakout group was the question whether it is possible 
to mentally manage the recursive composition of ’small’ interfaces. If this is the 
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case, then disadvantages such as the run-time overhead remain, but this is coun- 
tered by the better testability of small component interfaces. The granularity of 
components is a compromise between conflicting forces. 

The breakout group explored the relation between the problem size and the 
solution size. Assuming that the problem has predefined domain instances, the 
solution domain can be organized in components of the ’right’ granularity while 
maintaining scalability. 

Finally, the notion of a compositional language was discussed that would 
allow us to compose components as easy as programming languages compose 
the syntactic elements of the language. The assumption was that the availability 
of such a language would positively influence our ability to scale, but no language 
proposal was presented. 

2.5 Variability 

A topic that received no or minimal attention during earlier years is the notion of 
variability, i.e. predefined variation points at which available or newly developed 
variants can be bound to obtain the required behaviour from the instantiated 
component. The breakout group identified three relevant activities, i.e. discov- 
ering, facilitating and implementing variability. The main issue with respect to 
discovering variability is how one identifies required variability and, once identi- 
fied, how one documents variation points. With respect to facilitating variability, 
the breakout group focussed on design patterns. Many design patterns separate 
stable and variant behaviour providing good means for facilitating variability. 
Finally, for the implementation of variability, several categories of mechanisms 
are available including structural flexibility, rule-based flexibility and supportive 
technologies. 

2.6 Degrees of Encapsulation 

The final topic addressed by a breakout group was encapsulation. The discussion 
start out from the question ”how much encapsulation can we afford?”. A certain 
degree of encapsulation -or information hiding- within components is needed to 
abstract from implementation details, to allow component implementations to 
be changed without invalidating all clients, and to achieve more context inde- 
pendence. On the downside, a totally encapsulated component is pretty much 
useless for a component user. There is a need for information about how to use 
the component, in particular, what is demanded from the component’s deploy- 
ment context. The more encapsulated a component is, the more careful it must 
be described how the surrounding system must look like. In today’s practice, 
most of these descriptions are not complete and lack some details. 

Further, the more a component actually becomes context independent, the 
more genericity gets build in, which has drawbacks on performance, complexity, 
etc. Finally, systems built of components need to be tested and components 
may need to be adapted to application-specific needs. Again, this may require 
access to component-internal details. From a component producer perspective. 
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the above discussion contains relevant questions as well. For instance, how to 
express quality attributes of a component and what aspects of a component are 
relevant for the users. 

The break out group concluded that there is no final and general answer yet to 
the issue of how much encapsulated a component may be. The hard issue is that 
component designers and producers need to guess what information component 
deployers and system testers will need later. More experience is needed. 

3 Concluding Remarks 

Concluding, we are able to state that, on the one hand, also the fifth workshop 
on component-oriented programming was a highly successful event that was 
appreciated by the participants, but, on the other hand, the issues surrounding 
component-oriented programming have not been solved and that future events 
remain necessary to further the state of the art. One interesting trend that we 
have identified over the years is a change in focus. Whereas the first workshops 
aimed at the individual components, especially during the last event there was 
a clear consensus that the focus should be on the component architecture, i.e. 
the cooperation between components. In particular, not the component-’wiring’ 
standards, such as CORE A, COM and JavaBeans, but rather the system design 
level issues, such as software architectures and component frameworks. 

Accepted Papers 

1. Object Oliver Stiemerling, Pascal Costanza and Armin B. Cremers (Univer- 
sity of Bonn, Germany) 

Identity and Dynamic Recomposition of Components 

2. Marie Jose Presso (France Telecom R & D, France) 

Declarative Descriptions of Component Models as a Generic Support for 
Software Composition 

3. Francisco Curbera, Sanjiva Weerawarana and Matthew J. Duftler (IBM T. 
J. Watson Research Center, U.S.A.) 

On Component Composition Languages 

4. P.J. ’t Hoen and L.P.J. Groenewegen (Leiden University, Netherlands) 
Abstract Plug in Components with Behaviour 

5. David Mennie and Bernard Pagurek (Carleton University, Canada) 

An Architecture to Support Dynamic Composition of Service Components 

6. Dietrich Birngruber and Markus Hof (Johannes Kepler University, Austria) 
Interactive Decision Spots for JavaBeans Composition 

7. Eddy Truyen (Katholieke Universiteit Leuven, Belgium), Bo Norregaard Jor- 
gensen, Wouter Joosen and Pierre Verbaeten (University of Southern Den- 
mark, Denmark) 

On Interaction Refinement in Middelware 

8. Robert Cherinka, John Ricci (The MITRE Corporation, U.S.A.), Michael 
Overstreet and Chris Wild (Old Dominion University, U.S.A.) 

Validation Concerns in Developing Component-based COTS Systems 




64 



Jan Bosch, Clemens Szyperski, and Wolfgang Week 



9. Joao Costa Seco and Luis Caires (Universidade Nova de Lisboa, Portugal) 
Parametric Typed Components 

10. Kris De Voider, Johan Fabry, Roel Wuyts (Vrije Universiteit Brussel, Bel- 
gium) 

Logic Meta Components as a Generic Component Model 

11. Denis Conan, Michel Coriat and Nicolas Farcet (Alcatel/Thomson-CSF 
Common Research Laboratory, France) 

A Software Component Development Meta-Model for Product Lines 

12. Magnus Larsson (ABB Automation Products AB, Sweden) and 
Ivica Crnkovic (Malardalen University, Sweden) 

Component Configuration Management 

13. Friend Stav (Norwegian University of Science and Technology, Norway) 
Component Based Environments for Non-Programmers 

14. Oscar Nierstrasz, Jean-Guy Schneider, Franz Achermann (University of 
Berne, Switserland) 
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Abstract. The objective of this workshop was to discuss current tools 
and environments for learning object-oriented concepts and to share ideas 
and experiences about the usage of computer support to teach the basic 
concepts of object technology. Workshop participants presented current 
and ongoing research. During the discussions the participants developed 
a general “package” of requirements for such tools and environments, 
which underlying pedagogical approaches could be applied, and how such 
tools and environments should look like. 



1 Introduction 

Successfully using object-oriented technology in a development project requires 
a thorough understanding of basic object-oriented concepts. However, learning 
these techniques has proven to be very difficult in the past. Misconceptions can 
occur during the learning cycle and the needed guidance can not always be 
directly provided. 

The goal of this workshop was to share ideas and experiences about the us- 
age of computer support in learning and teaching the basic concepts of object 
technology. This could be either tools used in environments, specific environ- 
ments for learning object-oriented, as well as any kind of support for developing 
object-oriented learning applications themselves. 

In order to develop useful results regarding the issue of understanding object- 
oriented concepts, the workshop wanted to focus on the following topics: 

— Computer-based learning of object-oriented concepts; 

— Intelligent environments for learning basic object-oriented concepts; 

— Frameworks or class libraries to support learning; 

— Microworlds for learning about the concepts of object-oriented technology; 

— Any other kind of tool support for learning object-oriented technology; 

— Frameworks or toolkits to support the development of teaching or learning 
applications. 

This was the fourth in a series of workshops on issues in object-oriented teaching 
and learning. Previous workshops were held at OOPSLA‘97 [ 112 ] . ECOOP‘98 [3] 
and OOPSLA‘99 g]. 



J. Malenfant, S.Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 65- 1771 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 
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Table 1. Workshop program 



Time Topic 



9.00 


am 


9.15 


am 


9.35 


am 


9.55 


am 


10.10 


am 


10.30 


am 


11.00 


am 


11.20 


am 


11.35 


am 


12.00 


am 


1.00 


pm 


1.15 


pm 


1.35 


pm 


2.00 


pm 


3.30 


pm 


4.00 


pm 


5.00 


pm 



WELCOME NOTE 

Close the window and put it on the desktop, presented by James O. 
Coplien 

A library to support a graphics-based object-first approach to CSl, pre- 
sented by Kim Bruce 

Introducing Objects with Karel J. Robot, presented by Joseph Bergin 
Experimentation as an aid for learning, presented by Dan Rozenfarb 
COFFEE BREAK 

Combatting the Paucity of Paradigms in Current OOP Teaching, pre- 
sented by Theo D’Hondt 

Minimalist Tools and Environments for Learning about Object-Oriented 
Design, presented by Mary Beth Rosson 

A Programming Language for Teaching Concurrent Object Oriented 
Concepts, presented by Laszlo Kozma 
LUNCH BREAK 

A Model-Oriented Programming Support Environment for Understand- 
ing Object-Oriented Concepts, presented by Stephen Eldridge 
Exploratorium: An Entry-Level Environment for Learning Object Tech- 
nology, presented by Jan Schiimmer and Alejandro Fernandez 
A Tool for Co-operative Program Exploration, presented by Torsten 

Holmer and Jan Schiimmer 
First Working group session 

COFFEE BREAK 

Second Working group session 

Wrap-up session 



2 Workshop Organization 

The workshop organizers wanted to gather people that were involved in the 
development or use of learning support for any kind of learning tool or envi- 
ronment. To get together a manageable group of people in an atmosphere that 
fosters lively discussions, the number of participants was limited. Participation 
at the workshop was by invitation only. Eighteen participants were selected on 
the basis of position papers submitted in advance of the workshop. 

The workshop was organized into two presentation sessions (all morning), a 
demo session (after lunch), two working group sessions (afternoon) and a wrap- 
up session, where all working groups presented their results. Table [1] summarizes 
the details of the workshop program. 

To gather some input for the working group sessions participants were asked 
to finish their presentations by raising a few central questions or problems that 
were (not) addressed by their position statement. Related questions and prob- 
lems were then grouped into working group topics. 
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3 Summary of Presentations 

This section summarizes the main points of all workshop presentations. More 
information on the positions presented at the workshop as well as further po- 
sition papers accepted for the workshop can be obtained from the workshop’s 
home page at http://prog.vub.ac.be/ecoop2000/. 

Jim Coplien gave an introduction and critical review on the Minimalist Ap- 
proach as a learning paradigm as proposed by John M. Carrol’s book “The 
Niirnberg Funnel” [5j. The basic idea of this approach is to support active, ex- 
plorative learning. Learners possess relevant knowledge and use it to make sense 
of new information. Real tasks should be embraced early. Only a minimum of 
guidance/instructions is given. This will lead to real mistakes, which can be used 
as a learning opportunity. 

The talk’s main point was that we have created an artificial dichotomy be- 
tween pedagogy and application, i.e. the usage of the knowledge acquired through 
education. Although we recognize that good pedagogy must include application, 
we ignore that good application must attend to pedagogy. Using a program is a 
learning experience, and a program should be designed with that in mind. 

“The Niirnberg Funnel” provides an extensive case study demonstrating that 
people are best at learning through experience and experimentation. Jim pointed 
out two important points overlooked by the book: 

— Much of the learning in the case studies involved mastering gross mismatches 
between the learner’s expectation and what the program provided; one can 
easily postulate that much of the learning would have been unnecessary had 
the program designers been more attentive to usability. 

— Learning and experimentation are an essential component of any human 
activity, including our daily use of both familiar and new computing tools. 
These behaviors are not limited to institutionalized pedagogy. That in turn 
suggests that the same mechanisms, tools, and design rules that apply to 
pedagogical environments should become the stock and trade of application 
developers as well. 

The talk concluded with a vision of going forward with interactive program de- 
sign: We should either get rid of all the programmers and have all programs 
written by developers of electronic learning environments, or we should get rid 
of all training software developers and let training emerge as a natural outgrowth 
of the use of tools that support the learning process. This approach could build 
on a wealth of longstanding complementary practices, such as the direct manip- 
ulation metaphor, which software developers employ in the designs both of their 
systems and the interfaces by which users become acquainted with them. 

Kim Bruce presented experiences using the MagicDraw library developed at 
Williams College. MagicDraw was developed to support an “objects- first, graph- 
ics-first” approach for the teaching of Java in a CSl course. The library enables 
them to: 
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— Use an object-first approach, requiring students to think from the start about 
the programming process with a focus on methods and objects. 

— Use graphics and animation extensively. Using graphics was considered an 
important aspect of a tool both because students were able to create more in- 
teresting programs, and because graphic displays allowed students to receive 
visual feedback when they made programming errors. 

— Introduce event-driven programming early in the course. Most of the pro- 
grams students use today are highly interactive. Writing programs that are 
similar to those they use is both more interesting and more “real” to the 
students. 

— Introduce concurrency as a natural tool for program construction, especially 
when used in conjunction with animation. 

The interest in introducing the last two items early was motivated, in part, by 
Lynn Andrea Stein’s | 10| work on highlighting the importance of interaction in 
an introductory course. 

Using the library instructors can focus on getting the concepts across un- 
obscured by the complexities of language constructs, which are designed to be 
more flexible and powerful than needed in an introductory course. At the same 
time, the library was carefully designed to allow a smooth transition to the raw 
language facilities once the students are comfortable with the concepts. 

Joseph Bergin talked about Karel J. Robot, to support the introduction of 
object-oriented concepts in Java courses. Karel J. Robot is a successor of Karel 
the Robot, which was initially developed to introduce structured programming 
in Pascal to novices [9]. 

The idea of using a robot is that students are familiar with the concept 
of a robot. In the Karel world, robots live in a space that represents the first 
quadrant of the Cartesian plane, with horizontal streets at the integer points 
and avenues at the vertical points. There can be walls between the streets and 
avenues, and the world can contain beepers that the robots can pick up and 
carry. Furthermore, students can “act as a robot.” Behaving consistently with 
the associated metaphor makes it easy for students to understand what is going 
on in a program. 

Different versions of the robot exist, which are all built around pedagogical 
patterns mm- The most important pattern for the development of the approach 
taken by Karel J. Robot is Early Bird pattern. This pattern helps to order class 
topics in order of importance and find ways to teach the most important ideas 
early. 

Karel J. Robot courses start by teaching methods, objects, and classes, be- 
cause they are the prerequisites for teaching polymorphism (the key object- 
oriented concept, according to Joseph Bergin). Students develop programs by 
inheriting from existing Robot classes, refining their behavior. 

The Karel philosophy supports a Spiral Teaching Approach, i.e. students can 
successively deepen their knowledge while having the tools to build exploratory 
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programs from the start. The pedagogical foundings are well designed and the 
tools’ GUI’s are appealing. 

Experiences at Pace University are promising. Karel J. Robot has proven to 
be very successful in introducing object-oriented programming to novices. 

Dan Rozenfarb gave a talk on experimentation as an aid for learning. His 
main research area is the construction of domain-specific frameworks and the 
importance of experimentation to acquire knowledge. 

Learning is achieved through many different means. A single tool is therefore 
not enough to support the learning process. An appropriate learning environment 
needs a set of tools that trigger off experimentation and support various learning 
processes. 

The talks main points can be summarized as follows: 

— Experimentation is a way to learn and to acquire knowledge; 

— There are many factors that deter experimentation and learning, like 

• lack of immediate feedback, 

• lack of support for decision making, 

• limited undo facilities, 

• testing/debugging support (for partly finished classes), 

• indirect or no object manipulation, 

• too many classes and objects; 

— The need of an integrated environment with tools that facilitate experimen- 
tation; 

— A proposed set of tools that alleviate the problems. 

Reviewing the literature the following topics where consistently mentioned as a 
necessity for teaching object-orientation: 

— Complexity hiding and gradually revealing details; 

~ Integrated and live environments that help the students to concentrate on 
the main issues; 

— The need for us (the teachers) to define what is essential in the object ori- 
ented paradigm and what is not; 

— Emphasis on design issues from the very beginning; 

— The importance of showing the students that there is something different to 
Java. 



Theo D’Hondt was very concerned about the current trend in OOP teaching to 
use Java only as a (first-year) programming language. Because of the overwhelm- 
ing success of Java as “the” language for the internet, the continuous demand for 
skilled Java programmers has led to tremendous pressure on educational systems 
to promote Java as a first-year language. As a consequence, computer science 
graduates are no longer familiar with a wide range of programming paradigms. 

Going against this trend, Theo reported on his experience with Pico, a tweak- 
able language implementation for teaching, as a medium for learning all concepts 
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of object technology. Pico was used in an experiment within the context of a Eu- 
ropean Master on Object-Oriented Software Engineering [l4j. The students had 
very different backgrounds, so there was a strong need to establish a common 
ground among the group. 

Pico is a self-contained technological framework for uniting all relevant object- 
oriented concepts. It is a simple, dynamically typed language with automatic 
memory management similar to the Scheme language. Pico is tweakahle in the 
sense that moving from the original language to a derived language is very simple. 
Since every aspect of the language is first class, new features can be prototyped 
and moved out into the implementation of the actual virtual machine. 

Once the students managed the approach of the prototype-based version of 
Pico, they could easily describe a class-based tweak of the Pico language. 

Using a tweakable virtual machine as technological support proved to be 
extremely efficient. Using well-known concepts such as functions, closures, scop- 
ing, etc., it was possible to describe the semantic notions of the object paradigm. 
Theo believes that a similar but simplified approach can be successfully applied 
at the undergraduate level. 

Mary Beth Rosson talked about the problems of teaching design as a compo- 
nent of the standard object-oriented programming course offered by the Depart- 
ment of Computer Science at Virginia Tech. All of her work is example-based 
and grounded in the principles of minimalist instruction |^. 

The essence of minimalism is to assume from the start that learners possess 
a considerable amount of knowledge, and that they will use it in making sense of 
new information. Example-based learning is a powerful technique for minimalist 
instruction; examples can be complex and therefore more realistic, as long as 
appropriate guided exploration is provided. 

The intent of one project was to provide an overview of Smalltalk. The teach- 
ing materials were minimal, i.e. just enough to make experienced programmers 
curious and therefore learn the rest on their own. One of the objectives was 
to convey the MVC framework of Smalltalk. The learning materials to achieve 
this objective was a card game. At first, all Smalltalk code was hidden and the 
learners just interacted with a bare model. Afterwards, the code behind mes- 
sage sends was revealed. The exploration of this tool was supported by the View 
Matcher, a kind of specialized debugger. 

Because this tool proved to be quite successful, the same kind of tool was 
used to tackle the problem of reuse. Classes designed for reuse were documented 
implicitly by examples, and then the tool was used to explore these examples. 
This idea was based on the fact that expert programmers have a need to learn 
when they attempt to reuse a class, with the difference that they know much 
more to start out with. 

The minimalist approach proved to be quite successful for “getting people 
to do something.” An open problem is however, how this approach scales up to 
more complex maintenance or software engineering issues. 
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Lazio Kozma presented a language to teach and learn concurrency. Concur- 
rency is a natural concept, but not its realization inside a programming language. 
Different programming languages take different approaches, making it necessary 
to study a variety of programming languages to fully understand the concept. 
However, expecting students to learn a lot of languages to gain a deeper un- 
derstanding of concurrency is clearly undesirable. Concurrent object-oriented 
concepts could be understood more easily if we had a programming language 
providing kinds of tools to express concurrency and object-orientation at the 
same time. 

To achieve this aim an object-oriented extension to Pascal-FC (Function- 
ally Concurrent Pascal) was proposed. Pascal-FC was originally developed as a 
teaching language for concurrency that supports all major concurrency primi- 
tives present in current programming languages |^. 

In the object-oriented extension active objects are represented by processes 
and passive objects can be represented by monitors, resources, or processes. The 
central concept of concurrent object-oriented programming, besides concurrency, 
is knowledge-sharing, i.e. the re-use of object descriptions. The advantage of 
knowledge-sharing lies in increased modularity and hierarchical structuring. The 
tools for knowledge-sharing are subtyping and inheritance. 

As a model of computation a reflective model of objects was implemented. 
Different kinds of synchronization mechanisms were included into the language 
to avoid inheritance anomalies. The general object level synchronization schemes 
(guarded methods, synchronization with enabled sets, synchronizers, transition 
specifications and synchronization sets) were implemented as well. Users can 
develop a concurrent program using concurrent objects with different kinds of 
synchronization mechanisms. The abstraction level of these mechanisms is some- 
what different. Some mechanisms can be interpreted as either specification or 
implementation of synchronization of methods. To avoid inheritance anomalies 
the so-called sequential code of a method was separated from the synchroniza- 
tion code, so both codes could be inherited separately. 

Stephen Eldridge introduced us to MPSE, a Model-oriented Programming 
Support Environment (MPSE) designed specifically to support the teaching of 
fundamental and general concepts that underpin the object-oriented paradigm. 
The main aim of the environment is to teach the underlying concepts of object- 
orientation via the specification of the desired properties of objects and to ab- 
stract over programming language and implementation specific details. The fa- 
cilities provided by the MPSE support users whose level of skill changes signif- 
icantly over time and which abstract over the more sophisticated facilities pro- 
vided by conventional software development environments. The desired prop- 
erties of a program are modeled directly in terms of object types and their 
attributes. A simple notation called MODEL is used to capture the desired 
properties of object types independently of implementation considerations. 

Users interact with the system by directly manipulating objects whose at- 
tributes represent different kinds of description. The system has been used sue- 
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cessfully to support a wide variety of learning activities within the Computation 
Department at UMIST. The MODEL language is now suitable as a design lan- 
guage not just for use within a teaching system but also for more complex tasks 
and together with different concrete programming languages. A working proto- 
type of the MPSE has been developed. Currently the system runs on Macintoshs 
only, but it should be easily portable to different architectures. 



Jan Schiimmer and Alejandro Fernandez presented the Exploratorium, 
a cooperative learning environment especially designed to learn about build- 
ing object-oriented systems. The Exploratorium combines common features of 
object-oriented CASE tools with visualizations and animations of object-oriented 
applications. Its purpose is to improve students’ mental models of object-oriented 
systems by exploring the inner workings of real systems. Drawing on the expe- 
riences of both groups (GMD-IPSI [T^], and LIFIA [T2j) in the areas of ob- 
ject technology and cooperative learning environments, the Exploratorium is 
enriched with cooperation capabilities. 

Users of the system can explore the definition and behavior of a working 
application that serves as an example. All aspects of the example application can 
be explored and modified cooperatively, from its user interface to its definition 
in Smalltalk. Even the example applications UML object and class diagrams can 
be explored and modified cooperatively. 

Example applications are created by the teacher without the need of extra 
effort to include it into the exploration environment. The presentation included 
a demonstration of a prototype of the system where two users where coopera- 
tively exploring an example mail client. As ongoing work, the authors are still 
exploring and evaluating the results of using the application. Research is being 
done in the areas of cooperative system visualization and development. It is also 
of interest to develop guidelines for the construction of example applications that 
are rich enough to serve the purpose of learning, but at the same time simple 
enough to make their exploration feasible. 



Torsten Holmer and Jan Schiimmer talked about the integration of the 
Exploratorium of the former talk with an existing cooperative virtual learning 
environment named VITAL [15j . VITAL is a shared environment in which teach- 
ers and learners can create and annotate hypermedia documents in synchronous 
and asynchronous modes. A state of an Exploratorium can be linked to the hy- 
permedia structures of VITAL and thereby integrated into the shared learning 
and working material. This allows the training application (in the Explorato- 
rium) be tightly linked with the learning environment and therefore a faster 
switching between reading and annotating and creating and exploring new ob- 
ject structures. 

VITAL is written in VisualWorks Smalltalk (V2.5) and is thus available for 
all platforms supported by VisualWorks. Next steps are enhancing the stability 
of the prototype, looking for good object designs used in the Exploratorium, 
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developing concepts for courses which make use of these tools and the evaluation 
of the whole approach. 

The audience agreed that such an approach could be useful for learning. But 
the point was made that these concepts have a problem in real life, because most 
universities lack the technology needed to support this learning style. Another 
problem is that there are not enough teachers for teaching object technology 
in small groups. This facts still limit the application of cooperative learning 
software in the domain of teaching object technology. 



4 Main Results 



During the presentations workshop participants raised many interesting and 
challenging questions. These were grouped into four working group topics as 
follows: 

— “Natural” concepts vs. specific languages and tools 

• Is object-orientation a more “natural” approach to (software) develop- 
ment? 

• Should we start with (abstract) concepts or (concrete) languages? 

• Is UML a good representation for (object-oriented) models? 

• Is there any specific object-oriented design or object-oriented knowledge 
for tool design? 

— Scope and limitations of the minimalist approach 

• Are we learning by doing or doing by learning? 

• “Good design comes from experience, but experience comes from bad 
design” [Bergin] 

• Can we teach software engineering principles by learning by doing? 

• What if learners fear to make errors? 

— Objects vs. algorithms vs. concurrency 

• Are objects good for everything? 

• Concurrency - how early? 

— Tool support for (cooperative) learning 

• Cooperative learning and exploration - when, where, and how? 

• Meta-learning vs. tool overload - do we learn by using a tool or by learn- 
ing the tool itself? 

• What should a tool support or not support? 

Workshop participants voted for the four topics above and we ended up with 
three working groups. The working group Objects Vs algorithms vs. concurrency 
could not be filled. 

The discussions of the working groups are summarized in the subsections 
below. 
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4.1 “Natural” Concepts vs. Specific Languages and Tools 

One of the issues this group covered was that of richness of languages and how 
they support expressing models following different formalisms. The group con- 
sidered it important for languages to support specification, exploration, devel- 
opment, and reflection. Even though each member of the group had his/her 
favored (object-oriented) language the group agreed to some extent in the fact 
that the principles of objects could be taught using any of them. However, quite 
some time was dedicated to discussing the impacts that particular features of 
languages have on learning. Discussion topics included 

— typed vs. untyped languages, 

— concurrency, 

~ hiding complexity, 

— declarative specification, 

— genericity, 

— metamodeling, 

— prototyping, and 

— support for experimentation 

A big problem in using speciflc languages is that people tend to stick with the 
paradigm of the first programs they write. Although language does not matter 
in general, “just Java” is not enough. Custom designed teaching languages might 
be one solution to these problems. Another solution would be to change curricula 
and teach (formal) semantics first to build a common ground. Students can then 
pick speciflc languages more easily by themselves. 

4.2 Scope and Limitations of the Minimalist Approach 

Minimalist approaches assume active learners with a considerable amount of 
knowledge that they will use it in making sense of new information. Reading is 
kept to a minimum, things are done instead. The approach is very sensitive to 
the prerequisite knowledge of the learners and one needs to know the audience 
very well. 

It is still unclear how well minimalism fits group processes. There is a big 
difference between teaching someone a task that has such well-defined interfaces 
that it can be carried out in isolation (like writing a paper, where the mechanics 
of keystrokes and formatting are of no concern to the person providing the 
dictation nor to the recipient of the letter) and a task that interfaces with other 
tasks (such as most tasks of software development). That greatly limits the 
context in which minimalist instruction can be used. 

Certification courses or examination are another difficulty. How can we test 
what someone has learned? How can learning be tested? If we are to use mini- 
malist instruction, then we cannot draw testing material from the pedagogical 
material itself (because there is too little of this). That makes it more difficult 
to develop meaningful tests. What the minimalist system gains in “natural” 
mastery of a task it may sacrifice to inconsistency across learners or to lack of 
objective evaluation criteria drawn from the pedagogy. 
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4.3 Tool Support for (Cooperative) Learning 

The aim of this working group was to reason about educational tools for object- 
orientation; what should such tools support or not support, how should they be 
built, and and what pedagogy should be used? 

The group elaborated on three topics that cross cut the presentations of all 
position papers: 

— Hiding complexity 

— Meta-learning 

— Level of tool support 

The first issue was addressed by three presentations. The MagicDraw library, 
presented by Kim Bruce, hides more or less complex code inside specific classes. 
Students are freed from handling repaint loops, listeners, or concurrency. Karel 
J Robot takes this approach even further, but with a narrower application area. 
Mary Beth’s example-based tools (based on the minimalist approach) focus on 
concrete topics to learn. Details are hidden in layers that can be revealed step 
by step. 

All approaches proved successfully to enable students to manage nontriv- 
ial tasks early. The groups main conclusions about complexity hiding can be 
summarized as follows: 

— Leave students in a state of perceived total control, leaving mysteries (like 
Java’s public static void main (String [] args) ) causes only confusion; 

— Build layers on top of existing tools or environments that function as filters 
and try to gradually introduce all difficult parts; 

— Avoid a gap when unhiding. The revealed details should fit with the knowl- 
edge gained so far, “old” knowledge should not become invalid; 

Even the issue of meta-learning cross cut several presentations. The example- 
based tools used in minimalist instruction try to minimize meta-learning, whereas 
the Pico approach, presented by Theo D’Hondt, proposes the opposite. Learners 
must master the Pico framework in order to learn about object-oriented seman- 
tics. The saying that to really learn a programming language, you have to write 
an interpreter/ eompiler for it points into the same direction. 

A problem with meta-learning are its high start-up costs. It is not sure, 
if these costs will always pay back. In a traditional course environment, with 
limited schedules, the start-up costs might be prohibitive. Nevertheless, learning 
by means of a learning environment could mean using an authoring tool to adapt 
the learning environment itself 0. 

As its last issue the group discussed general requirements for learning/teaching 
tools. Unfortunately the group ran out of time, but could agree on the following 
list of minimum requirements: 

— A tool should be flexible enough to adapt it to different groups of users and 
application domains; 
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— It should support different views (of the problem and the solution) on dif- 
ferent levels of abstraction; 

— It should support syntax-directed editing and enforce good programming 
style in some way; 

— It should support visual programming to make learning more fun. 



5 List of Participants 

The workshop had 18 participants from 9 countries. Twelve participants came 
from academia and 6 from industry. All participants are listed in table [5] together 
with their affiliations and e-mail addresses. 



Table 2. Workshop participants 



Name 


Affiliation 


E-mail Address 


Isabel Michiels 


Vrije Universiteit Brussel, 
Belgium 


imichiel@vub.ac.be 


Alejandro Fernandez 


GMD-IPSI, Darmstadt, Ger- 
many 


casco@darmstadt.de 


Jiirgen Borstler 


limed University, Sweden 


jubo@cs.umu.se 


Maximo Prieto 


Universidad Nacional de La 
Plata, Argentina 


maximo@sol .info.unlp.edu.ar 


Eleonore Lundstrom 


Umed University, Sweden 


eason@informatik.umu.se 


Martine Devos 


EDS - Portfolio Development, 
Strat. 


mdevos@eds.com 


Xavier Alvarez 


EMN, France 


xavi@emn.fr 


Stephen Eldridge 


UMIST, Manchester, UK 


see@co.umist.ac.uk 


Jan Schiimmer 


GMD-IPSI, Darmstadt, Ger- 
many 


jan.schuemmer@gmd.de 


Torsten Holmer 


GMD-IPSI, Darmstadt, Ger- 
many 


torsten . holmer@gmd.de 


James 0. Coplien 


Bell Labs (& VUB), USA 


cope@bell-labs.com 


Mary Beth Rosson 


Virginia Tech, USA 


rosson@vt.edu 


Theo D’Hondt 


Vrije Universiteit Brussel, 
Belgium 


tjdhondt@vub.ac.be 


Kim Bruce 


Williams College, USA 


kim@cs.williams.edu 


Joseph Bergin 


Pace University, USA 


jbergin@pace.edu 


Dan Rozenfarb 


Universidad de Buenos Aires, 
Argentina 


drozenfa@dc.uba. ar 


Mikal Ziane 


Laboratoire de 1 ’universite 
Paris6, France 


Mikal.Ziane@lip6.fr 


Laszlo Kozma 


Edtuos Lorand University, 
Hungary 


kozma@ludens.elk.lu 
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Abstract. PhDOOS is a conference within a conference, rather than a tradi- 
tional workshop per se. Participants are Ph.D. students bound by a common 
interest in object orientation. This year, as in previous years, most participants 
presented a technical paper describing their research, with feedback from other 
participants forming the stimulus for ongoing discussion. Most participants also 
joined one of three distinct workshop themes, wherein particularly thorny 
research topics were explored collaboratively, with the aim of generating fresh 
insights and spotting potential research avenues for the future. 
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1 Workshop Aims 

This was the tenth annual PhDOOS workshop, held over two days (June 12 - 13, 
2000) in conjunction ECOOP2000. PhDOOS is an unusual workshop in that it does 
not aim to bring together researchers sharing a particularly common research goal. 
Rather, all attendees are Ph.D. students researching topics with a major emphasis on 
object orientation. 

PhDOOS runs essentially as a mini-conference within a conference, in that papers 
are submitted and reviewed, accepted papers are presented formally, a proceedings is 
published (albeit informally), and a series of workshops is held. The intent is to give 
participants exposure to presenting and interacting at conferences, to give the 
organizers exposure to running conferences, and to stimulate the cultivation of a 
research community. 

The acceptance rate of submitted papers is deliberately high, this year 
approximately seventy five percent of submissions were accepted. The aim here is to 
be inclusive rather than exclusive, providing encouragement to Ph.D. students to 
remain involved in conference-based exchange throughout and subsequent to 
completion of their Ph.D. studies. 



2 The Conference Program 

The first day and a half of the two-day program consisted of presentations of technical 
papers by most participants. At the end of each paper, five or ten minutes (for short 
and long papers respectively) were reserved for feedback. 

The technical program was organized into six distinct sessions. The range of 
accepted papers were so wide ranging that in many cases it was hard to group them. 
Even within each session, there was in many cases only a tenuous link between 
grouped papers. Each session, however, did at least provide a general theme around 
which to frame such unity. Each of the six sessions is elaborated in turn, below, 
describing (very briefly) the material presented, and highlighting notable feedback: 



2.1 Session 1: Advanced Applications 

Ela Hunt observed that object orientation enables us to tackle highly complex 
applications, but we need (and do not have) adequate support for that complexity in 
supporting databases. As an example, Ela described her work with biological (e.g. 
genome) sequence information. It transpires that existing database technologies lead 
to insufficient query performance on large data sets of this type. Ela has discovered 
that the novel application of 00 suffix tree indexes, over large volumes of sequence 
information, yields considerable performance increments. A prototype using the 
PJama persistent object system has demonstrated this effect. 

Rainer Ruggaber followed on from Ela by noting an emerging trend for wandering 
(nomadic) users demanding connection "anytime and anywhere." Rainer discussed a 
strategy (named P2) which utilizes a CORBA-based proxy on the mobile 
communicating with a partner proxy on the host to achieve transparent mobility. In 




80 



Anthony Lauder et al. 



response to audience feedback, Rainer discussed an approach for dealing with low- 
bandwidth wireless links via a new protocol based on significantly smaller packet 
headers than standard CORBA GIOP that resulted in a considerable performance 
improvement on, for example, GSM. 



2.2 Session 2: Theoretical Issues and Formal Approaches 

Johan Larsson introduced a novel extension to 00 languages called Polytypic 
Programming, which addresses problems with extensibility, modularity, parametric 
abstraction, and composition. Polytypic programming extends 00 type systems with 
higher levels of expressiveness, without an anticipated performance impact. The 
approach appeals to "kinds", which are essentially higher level types, enabling the 
development of generic programs independent of specific datatypes yet still 
constrained usefully. This is still an evolving theory, with integration of the polytypic 
approach with 00 continuing to unfold. 

Zoltan Porkolab highlighted a new measure of complexity for 00 programs 
(summing the complexity of control structure, data types, and data handling). The 
approach accommodates both the complexity of classes and the connectedness 
between them. The approach was claimed to demonstrate why object oriented 
programs are potentially simpler than their procedural counterparts. 

Charles Suscheck observed that frameworks for optimistic parallel discrete event 
simulation generally distort designs in favor of event objects rather than legitimate 
domain model inspired objects. Consequently, Charles has developed an Event 
Association Simulation package that hides events, are restores primary focus on 
domain objects. A set of superclasses is provided as an infrastructure for domain class 
creation and with mechanisms for realizing event notification and handling. 
Complexity metrics have demonstrated a noticeable reduction in complexity when 
this framework is deployed. 

Gilles Ardourel focussed upon 00-language access control mechanisms, where 
there are currenty only ad-hoc and diverse approaches available. Gilles has developed 
'access graphs' as a formalization of access control, allowing characterization, 
evaluation, and comparison of diverse mechanisms. Access graphs are being explored 
as a basis for software engineering tools, allowing sophisticated interrogation and 
manipulation of the access information expressed within such graphs. 



2.3 Session 3: Middleware and Distributed Systems 

Christopher Hess characterized file systems as typically treating data as unstructured 
contiguous chunks. Recognizing fully data as structured containers of object 
collections, though, would allow the realization of sophisticated parsing mechanisms, 
adaptive behavior, and distributed operations. Such awareness of the data (and its 
environment) deep within a novel filing system (2KFS) has enabled experimentation 
with a wide range of heterogeneous devices (PDAs, Cell Phones, etc) with filing 
system behavior adapted to the characteristics and location of each device. 

Chih-yung Chen is concerned with sharing of distributed objects which are subject 
to migration, and in particular how to achieve reliability in such an environment 
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without the levels of complexity encountered with existing schemes. Java and 
CORBA has been utilized to prototype a novel and efficient algorithm which achieves 
transparent fault tolerance, replication, and cache consistency, for distributed objects. 
A toolset is provided for application developers to utilize these facilities directly. 

Fernanda Baiao proposed a set of heuristics for handling fragmentation (both 
horizontal and vertical) of distributed 00 databases (seen as more complex than for 
relational databases), and has developed an algorithm that assists database designers 
with determining a suitable 00 fragmentation schema. Particularly interesting is the 
use of Theory Revision (from AI) to adapt that algorithm in the light of the needs of 
new applications. 

Nicodemos Damianou discussed the problems inherent in embedding distributed 
system security and management policies within the systems themselves - particularly 
the need to restart the system when policies change. Nicodemos observed that we can 
separate policy from the application via an extensible security policy language he 
terms Ponder. Ponder is a declarative 00 language, permitting the expression of 
authorization policies, action policies, meta-level policies, and so on. A toolkit is 
under development for defining, analyzing, and interpreting Ponder policies, targeted 
to any platform that supports Java. 



2.4 Session 4: Software Engineering 

Dietrich Bimgruber has been working with JavaBean composition, particularly 
introducing the concept of "bean plans" which a plan builder tool references to assist 
developers in valid composition. Bean plans (expressed in the novel BeanPlans 
scripting language) guide application programmers semi-automatically through the 
assembly process. The concept is currently in early prototype, and generates XML 
descriptions of composed beans, enabling their subsequent manipulation by other 
XML-aware tools. 

Elke Pulvermueller sketched an early application of Aspect Oriented Programming 
to separate out the concern of composition in software (both coarse and fine grained). 
A contract-oriented approach is envisioned, which synthesizes established approaches 
with new strategies expected to emerge from this work. In addition to Aspect 
Oriented Programming, Generative techniques are being investigated to automate 
component adaptation and composition. 

Johannes Martin is capturing problems typically encountered when moving legacy 
C applications to web-based Java replacements. Johannes is constructing automated 
tools which assist the migration process and strive to avoid the captured problems. An 
early focus has been upon aiding the transformation of implicit hierarchies (within C 
cast operations) to equivalent explicit class hierarchies in Java. 

Asmus Pandikow is concerned with the lack of integration between systems 
engineering tools and software engineering tools. For example, aircraft engineering 
has an ingrained emphasis on structured analysis, whereas supporting software is 
increasingly based on object oriented techniques. Strong entrenchment of the different 
stakeholders in respective approaches precludes standardization between them. 
Asmus, then, is working towards loss-less interchange between tools supporting the 
different approaches. An established project (SEDRES-2), capturing core concepts 
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from systems engineering, is being extended with object oriented concepts (from 
UML) to accommodate such interchange. 



2.5 Session 5: Distribution and Synchronization 

Ousmane Sy observed that CORBA IDL interface expressions are rather 
underspecified in terms of explaining the dynamic behavior of distributed systems. 
Ousmane has developed a tool (PetShop) via which IDL expressions can be 
elaborated with 00 Petri Net behavioral specifications enabling model verification 
and system prototyping. Particularly interesting what Ousmane's discussion of how 
PetShop has revealed incompleteness and ambiguity in the standard OMG Event 
Service, and in various commercial realizations of that service. 

Yunming Wang has developed a language named Behavior Expression (BE) to 
describe the behavior of objects. BE expressions are readily analyzable (e.g. for 
determinism) and also translatable into synchronous languages (such as SIGNAL). 
Taking this a step further, Yunming has recast UML statecharts in an elegant 
recursive formalism, simplifying their translation into BE, and hence into SIGNAL. 
Prototype tools have already been completed to perform this translation. The eventual 
aim of this work is to provide a completely integrated development cycle for 
distributed systems. 

Jose Luis Herrero Agustin discussed Separation of Concerns as a valuable design 
principle, well supported in emerging languages such as AspectJ. There has, however, 
been little exploration of this principle in the context of the design (rather than the 
implementation) of software. As a first step in filling this lacuna, Jose has extended 
UML semantics to accommodate Separation of Concerns, with particular emphasis on 
Synchronization as a separate concern. Tools have been developed by Jose to translate 
design expressed as separate concerns into executing program code. 



2.6 Session 6: Testing 

Phillipe Chevalley focussed upon testing, beginning by observing that randomly 
chosen test data is rarely effective. Rather, effective test data distribution must be 
underpinned by an understanding of the target domain. Domain models encapsulate 
such an understanding. Consequently, Phillipe has appealed to probabilistic 
techniques to generate effective test data from UML models constructed via Rational 
Rose RealTime. Empirical evidence has demonstrated more effective coverage than 
that achieved via merely random techniques. 



3 Workshops 

The second half of the second day covered the PhDOOS workshop program. 
Participants negotiated and organized themselves across three discussion groups 
according to mutual interest. Each discussion group then held a mini half-day 
workshop wherein their chosen topic was discussed, a particular problem within that 
topic was highlighted, and proposals towards the resolution of that problem were 
elaborated, negotiated, and eventually a group consensus committed to. At the end of 
the workshop program, all three discussion groups presented their findings, accepted 
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feedback, and committed to elaborating their findings further amongst themselves 
post conference. Each group was requested to write up their findings collaboratively, 
for inclusion within the current document (see appendix below). The three discussion 
groups for this year, then, addressed the following areas in their respective 
workshops: 

Workshop 1: Numerous emerging approaches to programming are enhancing object- 
oriented development with new and promising benefits. Examples included Aspect- 
Oriented Programming, Multi-Paradigm Programming, and Generative Programming. 
The participants in this first workshop were drawn to such "leading-edge" approaches, 
but had become somewhat troubled by the lack of standards in this area. After some 
discussion the question became "Do we need standards for leading-edge 
technologies?" A lot of ground was covered here, and the eventual consensus was that 
standards were indeed needed, but could perhaps only be realized beneficially via a 
novel layered approach elaborated by the workshop participants. 

Workshop 2: Practical experience with UML led a number of participants to 
encounter a worrying and potentially unmanageable "explosion" in the number of 
diagrams created. This was particularly true for sequence diagrams, which depict 
time-ordered inter-object collaboration. The aim of workshop 2 was discuss possible 
ways to reduce this explosion, perhaps by discovering alternate form of expression in 
sequence diagrams. It was hoped that the output from the workshop would be relevant 
to other forms of UML diagram, and not to sequence diagrams alone. 

Workshop 3: Although Object Orientation clearly gives benefits in software 
engineering terms, there was concern amongst some participants that these benefits 
potentially incur a performance penalty that is unacceptable for certain types of 
application. In particular there was anecdotal evidence that "00 generally requires the 
programmer to be smarter in order to implement efficient code". The aim of the third 
workshop was to scrutinize this claim, to separate fact from fiction, and ultimately to 
get a handle on where the tradeoffs lie and how to manage them. 



4 Concluding Remarks 

It was certainly rewarding running PhDOOS, and the organizers received much 
positive feedback from the participants. The 1 1* PhDOOS is already scheduled for 
next year and a number of this year's participants volunteered to be its organizers. All 
papers presented this year are available at the PhDOOS website 
( http://www.ecoop.org/phdoos) . as are details of the 00 Ph.D. Student Network to 
which all participant belong (and which potential future participants are encouraged to 
join). 

Many thanks are due. Firstly, thanks to the reviewers, whose thankless task was to 
decide which submissions did and did not make the grade. A big "thank you" from the 
organizers to Yossi Gil, our keynote speaker, who gave an excellent presentation on 
"Pascal, C, and Hilbert" which was both entertaining and inspiring. Thanks also to 
AITO - without their generous financial support several participants would have been 
unable to attend. Finally, thanks to the participants - you made it all worthwhile. 
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Appendix: Workshop Reports 



[Report from Workshop 1] 

Leading Edge in Object-Orientation: Do We Need 
Standards for Leading Edge OO Technologies? 



Elke Pulvermueller, Michael Haupt, Johan Larsson, Johannes Martin, 
David Statezni 



1 Introduction 

By the term “leading edge OO technology” we embrace the different approaches 
aimed at improving object-oriented software development. Some of those approaches 
are: 

• Aspect-Oriented Programming (AOP) ... encapsulates cross-cutting code in a 
new construct called aspect. 

• Subject-Oriented Programming (SOP) / HyperJ ... allows to build different views 
on an object. 

• Refactorings ... are behavior-preserving restructurings of object-oriented 
programs. 

• Multi -paradigm programming ... proposes to combine different programming 
languages and paradigms. 

• Generative programming ... aims at generating systems of system families. 

• Reflective programming ... means programming on the meta-level. 

• Domain-specific languages... are languages targeted at a particular problem 
domain. 

Our interest on these new technologies was driven by problems in the following 
areas: Domain-specific graphical modeling tools, Migration from C to Java, Lambda- 
Calculus in / and OO, Software composition. 

In the light of the existence of multiple new approaches various questions evolve. 
In our working group we explored the issue of standardization. We examined which 
role standards play in leading edge technology. Our guiding question was: “Do we 
need standards for leading edge technologies? ” 

In a general agreement we state that standards are one of the most important issues. 
This is not only true for current technologies but even more important for upcoming 
technologies in the future. Thus, generally speaking, standards should be built where 
possible and as early as possible. In the following we summarize our considerations 
about different questions in respect to standardization. 
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2 When to Standardize? 

There is discrepancy between the capability to standardize and the necessity. In the 
stages of early research building standards is counterproductive since it may inhibit 
research activities. On the other hand standards are necessary even during early 
research. Researchers, developers and early users have to coordinate with each other. 
Frequent changes in the interfaces, for instance, annoy the users and may lead to 
rejection. Also, early prototypes have to interact with the system environment. 
Exchangeability is a further point. 



3 What to Standardize? 

Looking at history one may assume that the standardization of a language is more 
difficult compared to systems based on interfaces. The programming language C++, 
for instance, had a “time to standard” of about 10 years. In contrast, the first CORBA 
standard was developed within about 2 years (1989 - 1991). A conclusion from this 
observation may be that if one wants to realize / implement a leading edge technology 
it is better to realize this by means of interfaces. These interfaces might be easier to 
standardize. 



4 How to Standardize / How to Improve the Standardization 
Process? 

Our group invented the notion of “layered standards”. This term describes a model 
for standards and their relationships as depicted in figure 1 . If we follow this scheme 
within a concrete system we get an instance of this model. This instance represents 
the standards used in a particular system and their relationships. 



fe 2 

« ii 



Programming Environment 
Programming Language 
Interoperability Standards 
Operating System 
Hardware 



Standards for Leading Edge 
Technology and supporting 
Tools 



Platform Standards 



Fig. 1. Layered Standards. 
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The most difficult question is how a standard can be established in a way that it is 
broadly accepted. Currently, standards are bom due to the power of industry. Only if 
there is a large number of companies willing to keep to this standard it will be also 
used by all the others. One reason for the existence of the de-facto standard Java, for 
instance, is that Sun Microsystems aggressively propagates this technology. Another 
example is the standard CORBA. It was built and supported by a large consortium of 
universities and - what is even more important - companies. 



5 Leading Edge Technology and Standardization in the Context of 
Some of Our Problems 

Two of the problems we discussed have been the problem of migrating C to Java and 
the problem of efficient support for composition. In the following these problems are 
outlined. 

• Problem: migration from C to Java. A lot of research has been done on the 
migration of procedural systems to object-oriented platforms. Migration from C 
to Java is special in that C does very little type checking while Java enforces type 
safeness very strictly. As C’s type looseness has been used in programs in many 
different scenarios, it is necessary to classify these scenarios and find methods to 
translate them into valid Java code. Refactoring is an important point here. 

• Problem: composition support. We employ leading edge technology to improve 
system development by stepwise refinement. Instead of stepwise refinement via 
inheritance our approach replaces these tight and implicit inheritance 
relationships by aggregation where the relationship itself is expressed and 
encapsulated in an aspect. In our work we used AspectJ to realize the aspects. 
Multiple version updates have been distributed from Xerox PARC during our 
work with this tool. This has been a difficulty for our research since we had to 
adapt to new interfaces and functionality multiple times. A standard would have 
helped us here. On the other side it was reasonable that there was no 
standardization on this field. Otherwise the concepts of AOP and the AspectJ tool 
would have dramatically decreased the speed of innovation. 
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[Report from Workshop 2] Managing UML 

Charles Suscheck, Marlon Dumas, Rainer Ruggaber 



1 Problem Statement 

With version 1.4 accepted by the OMG and version 2.0 pending release, the UML is 
becoming the de facto standard for documenting a software intensive system [1]. 
Applying the UML at a detailed level can lead to a large number of diagrams with 
complexity approaching the actual implementation. This is particularly evident in 
diagrams depicting the dynamic state and, in particular, sequence diagrams. The 
focus of our discussion group, then, was the identification of means for tackling this 
explosion of sequence diagrams. Basically three main problems were discussed: 

• A large number of sequence diagrams is needed to adequately diagram the 
dynamic behavior of even a moderately complex system. 

• Individual sequence diagrams can become complex. This can be due to the 
nature of the activities being modeled or the detail being depicted. 

• The relationship between sequence diagrams is not always clear. 

Sequence diagrams are very flat. Branching is limited, reuse of event sequences is 
non existent, and levels of abstraction are not employed. The UML 1.3 specification 
[2,3] allows for limited branching with a combination of focus of control, constraints, 
and message calls. Showing multiple paths on a single diagram can become 
complicated, even when flow of control is used to specify the scope of each branch. 

Sequence diagrams are typically not used to model the behavior of the entire 
system, but a series of fundamental activities. As the complexity of the system grows, 
it becomes necessary to produce additional diagrams. The individual diagrams and 
the relationship between the diagrams become complex. 

During the discussions, it was evident that people within the group applied the 
UML in various ways. For example, a sequence diagram could be tied to a use case 
in a one-to-one fashion or it could trace a particular thread of execution consisting of 
multiple use cases or a subset of one use case. A series of sequence diagrams could 
be used to document only major activities within a system or to document nearly 
every activity. Evidently, then, personal preference and the problem at hand heavily 
influence determining what to document and how to tie diagrams together. 



2 Proposed Solutions 

Our discussion group applied abstraction to segments of sequence diagrams by 
creating sub-diagrams that can be used as entities within sequence diagrams. We 
further propose implementing hyperlinks within UML CASE tools to relate diagrams 
together to make navigation more convenient. 

Representing objects and their sequence of activities as a sub-diagram is useful in 
mitigating the complexity of individual sequence diagrams. Branching can be shown 
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cleanly, levels of abstraction can be maintained, and a repetitive sequence of events 
can be shown as a single object. 

Sub-diagrams can be inserted at any point to represent abstractions of activities. 
Using sub-diagrams to represent logical groups of activities can act as a point to 
abstract details from a sequence diagram that are not necessary to the understanding 
of the sequence being depicted. Additionally, each sub-diagram can be shown in 
multiple sequence diagrams, fostering fan in of the functionality. By representing one 
or both branches of a condition as a sub-diagram the details of the branch can be 
captured at a more appropriate level of abstraction. 

The relationship between diagrams and their sub-diagrams becomes very 
important. We propose using hyperlinks to explicitly relate the diagrams. A 
sequence diagram can contain hyperlink to the sub-diagrams it refers to. Hyperlinks, 
though, are limited in that they have no parameters (as functions do), reducing the 
potential reusability of sub-diagrams. For instance, if a sub-diagram describe an 
interaction between two objects, then it could be modeled as a kind of function with 
two objects as parameters. 

Unfortunately, using sub-diagrams will most likely increase the total number of 
diagrams within the system. However, the diagrams would be less complex and their 
relationships would be made explicit through hyperlinks, thus increasing readability 
of the overall specification. 

3 Application of Solutions 

^ig^jjshows a sequence diagram with three sub-diagrams. Each sub-diagram shown 
in the main diagram is related to the detailed specification of the sub-diagram via a 
hyperlink. Sub-diagram 1 shows an example of abstraction. The details of the sub- 
diagram are not important to the sequence beindepicted. Fig. 1 shows branching from 
instance 1 to Sub-diagram 2 and sub-diagram 3. The branching construct from 
instance 1 conforms to the UML 1 .4 specification. The focus of control bar on sub- 
diagrams 2 and 3 are necessary since the sub-diagrams return values. If the sub- 
diagrams do not return a value, no focus of control is necessary. 



instance 1 



instance 2 



Sub-diagram 1 



Sub-diagram 2 



Sub-diagram 3 
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Fig. 1. A Diagram with Subdiagrams and Branching 



PhDOOS 2000: The 10* Ph.D. Workshop on Object-Oriented Systems 



89 



Fig. 2. shows an example of a sub-diagram. A given sub-diagram must clearly show 
an entry point. An exit point is only needed if the sub-diagram returns data. Sub- 
diagrams can contain sub-diagrams. 




4 Conclusion 

Although the UML is a well thought out specification language and is extraordinarily 
flexible, certain weaknesses exist when applying the UML. Even within our group of 
Ph.D. students, variations in application were evident. As the UML matures, it seems 
reasonable that a more homogenous technique for applying the UML will emerge. 
This report presents a small step in managing the sequence diagrams of the UML, 
focusing on reducing the sheer mass of diagrams needed to succinctly specify the 
dynamic nature of even a small system. We apply abstraction to segments of 
sequence diagrams, making sub-diagrams that can be used as first class entities within 
sequence diagrams. We then propose using hyperlinks in UML specification tools to 
make navigation of the sub-diagrams more convenient. Our proposal addresses the 
problems of complexity of individual sequence diagrams and the ambiguous nature of 
relationships between diagrams. 

Translating sequence sub-diagrams related through hyperlinks into flat sequence 
diagrams, is an interesting issue. Indeed, this translation is necessary in order to reuse 
the technology that has been developed around UML (e.g. consistency verification 
and code generation tools). In addition, this translation is non-trivial, particularly 
when the sub-diagrams are related through branching conditions as in figure 1 . 
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[Report from Workshop 3] 

Performance Issues in Object-Oriented Programming 

Christopher Hess, Gilles Ardourel, Fernanda Baiao, Philippe Chevalley, Ian Oliver, 

Zoltan Porkolab 



Large software development projects are difficult to design and implement. As the 
size of software projects increase, significant energy may be expended by tracking 
down bugs, and new bugs may be easily added when it is not clear how parts of a 
software system influence others [2], Object-oriented (00) programming enables 
abstraction of functionality and encapsulation of implementation behind interfaces 
and often results in the introduction of fewer bugs [8]. 

With the performance and capacity of machines increasing dramatically each year 
and software programs becoming larger, the maintainability and understandability of 
code often out- weighs efficiency concerns. Object-oriented programming has been 
hailed for its ability to model physical objects, enable code reuse, and increase 
expressiveness. 

The three concepts that generally define an 00 language are encapsulation, 
inheritance, and polymorphism. These features may introduce some performance 
penalties, which may be unacceptable to certain applications. 

Encapsulation generally requires the use of getters and setters to access data. Such 
methods can usually be optimized away by a good compiler. Single (non-virtual) 
inheritance usually does not introduce any overhead, since the data comprising the 
object is a combination of the derived class and all base classes into contiguous 
memory. Polymorphism does add some overhead, which is generally attributed to the 
level of indirection that the virtual function table introduces. However, a similar 
procedural program would need to replace the virtual function table with a case-style 
statement, which would negate any overhead. A real penalty occurs since the 
compiler cannot provide optimizations because binding is done at run time and cannot 
be known by the compiler. 

Often it is prudent to start with a good software design and optimize critical 
sections after those parts have been identified to be performance bottlenecks. Some of 
the penalties often associated with 00 can be avoided if one knows what is actually 
going on "under the hood" and what optimizations the compiler is performing. 
However, 00 compilers (e.g., C++) are maturing and are able to better optimize code 
without requiring such understanding. 

Since the way a class is implemented can affect efficiency, the programmer must 
be knowledgeable of when the compiler is generating code and must be careful to 
construct classes appropriately for the particular situation; many of the inefficiencies 
may be avoided if one is aware of these issues. For example, C++ objects may be 
classified into five categories: plain old data (PODs), featherweight classes, 
lightweight classes, middleweight classes, and normal-weight classes [6]. These types 
differ in what code is generated by the compiler, i.e., the default constructor, the copy 
constructor, the copy assignment operator, and the destructor. 

PODs are minimal classes that are equivalent to C structures and are equal in 
efficiency to C code. Featherweight classes are super-sets of PODs, except that 
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explicit invocation of the default constructor will zero-initialize the member variables, 
where PODs do nothing. 

Featherweight classes are a subset of the lightweight classes, but includes a user 
defined constructor. This can have implications when arrays of objects are defined. 
Since destructors of already constructed objects in the array may need to be called if a 
constructor throws an exception, some implementations may delegate construction to 
a function, adding overhead to the initialization process. 

Middleweight classes contain only a trivial destructor., reducing overhead when 
objects are destroyed. Since thrown exceptions require the compiler to destroy objects 
when unwinding the stack, defining explicit destructors requires the compiler to 
generate the mechanism to handle destruction, which may involve the creation of a 
table for this purpose. 

Since there are more ways to implement classes versus standard C structures, 
programmers must be aware of the intricacies of the C++ object model [4]. 00 
generally requires the programmer to be smarter in order to implement efficient code. 

Although 00 program design can add some overhead to program efficiency, some 
of the overhead has been misconstrued as excessively large. For example, there has 
been a misconception that C++ templates (for compile-time polymorphism) create 
code bloat; yet in general, templates reduee code bloat [7]. For example, most C++ 
compilers usually only include those template methods that are actually used, thus 
eliminating unused portions. A valid concern of bloat is when templates are used with 
pointer types. However, this problem may be resolved by using template 
speeializations [8]. A specialized template may be built for generic (void) pointers. 
Partial speeializations may then be used so that templates using specific pointer types 
may share the complete specialization. 

Object-orientation allows more elegant code design than procedural languages and 
such designs are often chosen even for performance-critical applications. For 
example, the lean implementation of the Linux operating system uses 00 teehniques 
to provide a more organized structure in its file system design. The Virtual File 
System (VFS) enables different file systems to be used with a single framework by 
using a strueture of function pointers to standard file interface methods [1]. This is 
similar to the virtual function table (viable) in C++ classes with virtual functions. All 
methods are accessed through pointers to functions that must adhere to the correct 
signature. 

Different file system types may be installed by replacing the structure of function 
pointers. Although the Linux C function pointer structure is similar to the C++ viable 
equivalent, the C++ syntax using polymorphie elasses is much cleaner and easier to 
understand. C++ provides the mechanisms necessary to more naturally implement 
polymorphism with similar performance and in a safer and more flexible manner 
without the need for confusing programming tricks. 

Execution speed is not the only measure of performanee. In the fast-pace of 
software development, the speed at which programs can be brought to market is 
important. Programmer productivity can be increased via the use of design patterns 
[3], providing a language for programmers to communicate ideas and code structure. 
Rather than wading through lines of code, a pattern can be identified and the strueture 
of eode may be immediately apparent. Patterns, though, often introduce some 
overhead in programs by often adding a layer of abstraetion. For example, the 
NullObject pattern generates a new object that does nothing [5]. This could be 
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replaced with a NULL pointer, but the code then becomes riddled with checks for 
NULL, which complicates the code and adds code specific to this special case. Design 
patterns increase program structure, which in many applications out-weighs efficiency 
concerns. 

As programs get larger and include more features, the amount of code that 
programmers must understand grows. Clean design, structure, and organization of 
code is crucial to maintaining a large code base, while introducing fewer bugs. 00 
code typically requires less lines of code to write, since tasks may be abstracted 
within classes. 00 allows the internal mechanisms of code to be hidden from the 
programmer and prevents inadvertent bugs from being introduced by limiting access 
to private software structures. However, along with the increased number of features 
and functionality of 00 languages comes an increase in complexity. 00 can add 
overhead to applications, so the programmer must be aware of when to use particular 
features. When efficiency is critical, some of these features may have to be sacrificed. 
However, when designing any software systems, a tradeoff exists in efficiency and 
maintainable code. Very efficient code is often difficult to maintain and the small 
performance penalty incurred by 00 languages is often far out-weighed by the 
increase in flexibility and robustness of the resulting code. 
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Abstract. This report summarizes the contributions and discussion of the 4* 
ECOOP Workshop on Quantitative Approaches in Object-Oriented Software 
Engineering held in Sophia Antipolis on Tuesday, June 13, 2000. This 
workshop aims to provide a forum to discuss the current state of the art and the 
practice in the field of quantitative approaches in the OO field. This year, three 
aspects were particularly discussed: formal approaches, empirical studies and 
measurement of analysis and design models. Nine position papers were 
presented and discussed. 



1 Introduction 

Measures of software internal attributes have been extensively used to help software 
managers, customers and users to characterize, assess, and improve the quality of 
software products. Many large software companies have intensively adopted software 
measures to increase their understanding of how (and how much) software internal 
attributes affect the overall software quality. Estimation models based on software 
measures have successfully been used to perform risk analysis and to assess software 
maintainability, reusability and reliability. However, most measurement efforts have 
focused on, what we call today, "legacy technology". 

The OO paradigm provides more powerful design mechanisms. Much work is yet 
to be done to investigate analytically and/or empirically the relationships between OO 
design mechanisms, e.g., inheritance, polymorphism, encapsulation, usage, etc., and 
different aspects of software quality, e.g., modularity, modifiability, 
understandability, extensibility, reliability, reusability, etc. Furthermore, new 
technologies, e.g., OO frameworks, OO Analysis/Design Patterns, OO architectures, 
OO components, which take advantage of OO design mechanisms have been 
proposed in order to improve software engineering productivity and software quality. 
However, to better understand the pros and cons of these technologies on products 
developed using them we must be able to assess the quality of such products via 
adequate software product measures. 

J. Malenfant, S. Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 93-103, 2000. 
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2 Workshop Organization and Presentation 

This workshop is a direct continuation of three successful previous workshops, held at 
ECOOP'99 (Lisbon), ECOOP'98 (Brussels) and ECOOP'95 (Aarhus): 

• The "Quantitative Approaches in Object-Oriented Software Engineering" 
workshop at ECOOP'99 (organizers: Fernando Brito e Abreu, Horst Zuse, Houari 
A. Sahraoui, Walcelio Melo) 

• The "Object-Oriented Product Metrics for Software Quality Assessment" 
workshop at ECOOP'98 (organizers: Houari A. Sahraoui, Sandro Morasca, 
Walcelio Melo) 

• The "Quantitative Methods for Object-Oriented Systems Development" workshop 
at ECOOP'95 (organizers: Horst Zuse, Brian Henderson-Sellers, Fernando Brito e 
Abreu) 

Submissions were requested in four areas: metrics collection, quality assessment, 
metrics validation and process management. In this year's workshop, a good coverage 
of all subject areas was obtained. A number of submitted papers even addressed 
topics belonging to more than one area. 

The workshop was organized in 3 presentation sessions followed by a global 
discussion. The content of the sessions was the following: 

Session 1: Formal Approaches to Metric Definition 

- A Formal Approach to Building a Polymorphism Metric in Object-Oriented 
Systems 

- Quantitative Assessment of the Significance of Inconsistencies in Object-Oriented 
Designs 

Session 2: Empirical Studies with Quality Metrics 

- Class Cohesion Revisited: An Empirical Study on Industrial Systems 

- Using Fuzzy Threshold Values for Predicting Class Libraries Interface Evolution 

- An Empirical Study with Object-Relational Databases Metrics 

Session 3: Measurement of OO Analysis Models, Design Models, or Conceptual 
Models 

- A Sizing Approach for 00-environments 

- On the Measurement of Event-Based Object-Oriented Conceptual Models 

- A Cognitive Model for Complexity Metrics 

- Measuring Object-Oriented Software Architectures from UML Diagrams 

The workshop gathered 14 people from 10 different countries (4 continents). 
Names and affiliations of participants are as follows: 

Fernando Brito e Abreu, UNL and INESC, Portugal 
Coral Calero, University of Castilla-La Mancha, Spain 
Daniel Deveaux, Universite de Bretagne Sud, France 
Anne-Marie Hugues, ESSI and UNSA, France 
Hind Kabaili, Universite de Montreal, Canada 
John Kammelar, IQUIP Informatica B.V., Netherlands 
Heoseab Kim, City University, London, United Kingdom 
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Tom Klemola, University of Technology, Sydney, Australia 

Lili Nenonen, University of Helsinki, Finland 

Luis Olsina, UNLPam, Argentina 

Geert Poels, Katholieke Universiteit Leuven, Belgium 

Claudia Pons, Universidad Nacional de La Plata, Argentina 

Houari Sahraoui, Universite de Montreal, Canada 

George Spanoudakis, City University, London, United Kingdom 

To bring some life in the workshop discussions we organized a little game. Each 
workshop attendee had to write his/her name on a piece of paper, which was put in a 
hat. After each paper presentation, an innocent hand would draw a name from the hat, 
and the "winner" was expected to put the first question, opening the discussion of the 
position paper. This arrangement turned out to be very effective. 

We also asked each attendee to summarize the contributions and limitations of the 
research presented. Again, this greatly helped to stimulate the workshop discussions. 



3 Discussed Topics 

3.1 Formal Approaches to Metric Definition 



3.1.1 A Formal Approach to Building a Polymorphism Metric in Object- 
Oriented Systems (Authors: Claudia Pous, Luis Olsina, and Maximo Prieto) 

Position Abstract 

Although quality is not easy to evaluate since it is a complex concept compound by 
different aspects, several properties that make a good object-oriented design have 
been recognized and widely accepted by the software engineering community. We 
agree that both the traditional and the new object-oriented properties should be 
analyzed in assessing the quality of object-oriented design. However, we believe that 
it is necessary to pay special attention to the polymorphism concept and metric, since 
they should be considered one of the key concerns in determining the quality of an 
object-oriented system. 

In our work, we have given a rigorous definition of polymorphism. On top of this 
formalization we propose a metric that provides an objective and precise mechanism 
to detect and quantify dynamic polymorphism. The metric takes information coming 
from the first stages of the development process giving developers the opportunity to 
early evaluate and improve the quality of the software product. Finally, a first 
approach to the theoretical validation of the metric is presented. 

Position Discussion 

Claudia presented a formal model of dynamic polymorphism and Luis presented the 
metric definition based on that model as well as a measurement theoretical validation. 
The presentation was followed by some questions to the presenters. Some of them are 
summarized bellow: 
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Q (Fernando): What about measuring polymorphism when methods have the same 
name and signature but a different behaviour? 

A: Behavioural equivalence is the criterion to decide on the type of polymorphism 
that can be measured with the proposed metric. 

Comment: Many workshop attendees admitted to be more familiar with Fernando's 
definition of polymorphism. This is anyway the notion of polymorphism that is 
usually used in empirical software engineering studies and for which measures have 
been proposed. 

Q (George): What about applying the measure during analysis and design? 

A: To calculate the measure a detailed statechart is required, and this is not always 
available in the early stages. 

Q (George): Why using dynamic logic in the formalization and not for instance the 
Object Constraint Language? 

A: Dynamic logic is more expressive. 

Q (Anne-Marie): What is the effect of dynamic polymorphism on quality? 

A: We haven't investigated this, but other studies have. Anyway, further studies on 
the quality effects of dynamic polymorphism are needed. 

Q (Houari): Is a high level of polymorphism an indicator of good quality? 

A: Polymorphism is usually not mentioned as a quality, for instance not in the ISO 
framework, which mentions only high-level quality characteristics. 

Q (Tom): Have you compared different models from the same domain with different 
polymorphism values? 

A: Our measure is an absolute measure. Further work is needed to put this measure 
into a wider framework. 

Q (Geert): Is it always possible to partition a system as required by the view on 
polymorphism expressed in the paper? Can the measure be applied if the system is 
not a partition? 

A: Partitioning is always possible. 



3.1.2 Quantitative Assessment of the Significance of Inconsistencies in Object- 
Oriented Designs (Authors: George Spanoudakis and Hyoseob Kim) 

Position Abstract 

This work consists in a framework for assessing the significance of inconsistencies 
which arise in object-oriented design models that describe systems from multiple 
perspectives. The framework allows the definition of significance criteria and 
measures the significance of inconsistencies as beliefs for the satisfiability of these 
criteria. 



Position Discussion 

George presented the work. Four aspects of this work were discussed as summarized 
bellow: 
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Q (Fernando): How can software engineers use this approach? 

A: Software engineers specify consistency rules, for instance in the Object Constraint 
Language, and these sentences can be associated to the classes in the UML meta- 
model. Software engineers then also specify the significance criteria using the 
proposed framework and language. Both tasks form the global framework for our 
research. 

Q (Luis): What meaning can be assigned to the numbers produced by the measures? 

A: The measures are belief functions, so the numbers express likelihoods. These can 
be combined. 

Q (Geert): What about empirical investigations into the main premise of the 
framework, i.e. the conjecture that the significance of inconsistencies is the same as 
the significance of the model elements in which these inconsistencies occur? 

A: We have examined this by means of judgments of the persons that constructed the 
models. Rank order correlation was used in this process. Further experiments are 
conducted. 

Q (Hind): Should the software engineering requirements be formulated manually or 
automatically? 

A: We are working on automation using a subset of OCL. 

3.2 Empirical Studies with Quality Metrics 

3.2.1 Class Cohesion Revisited: An Empirical Study on Industrial Systems 
(Authors: Hind Kabaili, Rudolf F. Keller, Francois Lustman, and Guy Saint- 
Denis) 

Position Abstract 

The assessment of the changeability of software systems is of major concern for 
buyers of the large systems found in fast-moving domains such as 
telecommunications. One way of approaching this problem is to investigate the 
dependency between the changeability of the software and its design, with the goal of 
finding design properties that can be used as changeability indicators. In the realm of 
object-oriented systems, experiments have been conducted showing that coupling 
between classes is such an indicator. However, class cohesion has not been 
quantitatively studied in respect to changeability. In this research, we set out to 
investigate whether low cohesion is correlated to high coupling and thus is a 
changeability indicator, too. As cohesion metrics, LCC and LCOM were adopted, and 
for measuring coupling, the Chidamber and Kemerer coupling metrics and variants 
thereof were used. The data collected from three test systems of industrial size 
indicate no such correlation. Suspecting that the cohesion metrics adopted for the 
experiment do not adequately capture the cohesion property, we analyzed manually 
the classes with lowest cohesion values. We found various reasons why these classes, 
despite of their low cohesion values, should not be broken into smaller classes. We 
conclude that cohesion metrics should not only be based on common attribute usage 
between methods and on method invocation, but also on patterns of interaction 
between class members and, ultimately, on the functionality of methods and 
attributes. 
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Position Discussion 

The work was presented by Hind. The discussion was as follows: 

Q (Hyoseob): What about coupling as an indicator of changeability? 

A: This study is part of a project investigating design properties as changeability 
indicators. This paper focuses on cohesion, not on coupling. 

Q (George): What logical definition of cohesion is used in the study? 

A: Cohesion as captured by measures like LCOM (Chidamber & Kemerer) and LCC 
(Bieman & Kang). The study showed that these measures are not indicators of 
changeability, suggesting that they do not reflect the real cohesion of a class. 

Q (Houari): An hypothesised relationship between cohesion and changeability is 
based on the fact that coupling is a good indicator of changeability. Therefore the 
study investigates if there is a relationship between coupling and cohesion. But why 
did you not directly investigate the relationship between cohesion and changeability? 
A: We wished to prove two things at the same time. 

Q (Houari): How can the real changeability of a system be captured? 

A: A change impact model must be used and artificial changes must be generated. 
Comment (George): The frequency of changes must also be taken into account. 

Q (John): What is the definition of changeability used in the study? 

A: Something is changeable if it is easy to modify. 

Q (Luis): What about the theoretical validity of the measures used in the study? 

A: The focus of the paper is only on the correlation study. 

3.2.2 Using Fuzzy Threshold Values for Predicting Class Libraries Interface 
Evolution (Authors: Houari A. Sahraoui, Mounir A. Boukadoum, and Hakim 
Lounis) 

Position Abstract 

This work presents a technique to circumvent one of the major problems associated 
with building and applying techniques to build software quality estimation models, 
namely the use of precise metric thresholds values; we used a fuzzy binary decision 
tree to investigate the stability of a reusable class library interface, using structural 
metrics as stability indicators. To evaluate this new approach, we conducted a study 
on different versions of a commercial C++ class library. The obtained results are very 
promising when compared to those of two classical machine learning approaches. Top 
Down Induction of Decision Trees and Bayesian classifiers. 

Position Discussion 

Presented by Houari, this work leaded to the following discussion: 

Q (Lili): How does this help to predict maintenance? 

A: It helps to focus on a subset of classes, i.e. those most prone to evolve in the next 



version. 
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Q (Luis): How to get the values in the decision tree? 

A: The algorithm determines the most discriminating values, i.e. a maximum number 
of examples that go in one way or another in a decision node. 

Q (John): What metrics are needed? 

A: This depends on the hypothesis that must be tested. In this case we used 
inheritance metrics, but we could as well have focused on coupling metrics as 
potential indicators. 

Q (George): Why do you need to build a tree if the changes are known? 

A: The changes are known for the historical data. These data will help us to derive a 
tree that predict evolvability for the next versions, where the changes are not known 
yet. 

3.2.3 An Empirical Study with Object-Relational Databases Metrics (Authors: 
Mario Piattini, Coral Calero, Houari Sahraoui, and Hakim Lounis) 

Position Abstract 

It is important that the software products, and obviously databases, are evaluated for 
every relevant quality characteristic, using validated or widely accepted metrics. It is 
also important to validate the metrics from a formal point of view in order to ensure 
their usefulness. However, into the aspects of software measurement, the research is 
needed, from theoretical but also from a practical point of view. So, it is necessary to 
do experiments to validate the metrics. We have developed an experiment in order to 
validate some object-relational databases metrics. The experiment was done in CRIM 
(Centre de Recherche Informatique de Montreal) from Canada and repeated on the 
University of Castilla-La Mancha from Spain. The results obtained on both 
experiments were very similar, so we can conclude that some of the proposed metrics 
seem to be good indicators for the maintainability of a table. 

Position Discussion 

Coral presented the work. The discussed points are the following: 

Q (Luis): How do you get the values for the rules? 

A: The values were obtained using machine learning techniques. 

Q (Fernando): Can maintainability really be considered as a boolean characteristic, as 
done in the study? 

A: In fact, we measure the understandability which is a subcharacteristic of 
maintainability (easy vs. hard to understand and then to maintain). 

Q (Fernando): What is the effect of using the metric collection process itself to assess 
maintainability? 

A: Actually, what is measured is understandability. We think there is no problem 
using the metric calculation for this aspect because there is no correlation between the 
metric formula and its value. 

Q (Geert): The same subjects are repeatedly given the same task, i.e. to calculate a 
metric using its formula. How to control for learning aspects? 
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A: They were given a mini-tutorial first, so everyone was familiar with the formula 
before the experiment started. The tables were given in a random order and not by 
database. 

Q (George): Why not ask subjects to write queries instead of calculating a metric? 

A: This is only a first experiment. We are setting a new experiment with a more 
objective way to measure the understandability. 



3.3 Measurement of OO Analysis Models, Design Models, or Conceptual Models 

3.3.1 A Sizing Approach for OO-Environments (Author: John Kammelar) 
Position Abstract 

Function Point Analysis (FPA) is by far the most popular high quality sizing method 
for a traditional development environment. It complies to certain degree to the ISO 
standards for a 'Functional sizing method' (FSM). When FPA is applied to Object 
Oriented development methods the OO concepts and characteristics have to be 
translated into FPA terms. As a result the outcome of the function point count is 
difficult to relate to effort estimation. But the need for a seamlessly fitting Functional 
sizing method (FSM) for 00-environments is growing fast now in the emerging 
environment of Component Based Development (CBD). This work proposes a new 
FPA-alike estimation technique for 00-environments in such a way that the 
determined functional size is composed from elements which may be candidates for 
reusable software components. This approach is not considered a final product but 
rather as a starting point for further elaboration to develop an estimation approach for 
CBD. 

Position Discussion 

John presented his position. This position was discussed as shown by the following 
questions: 

Q (Fernando): Have component object points been incorporated in an estimation 
model? What about calibrating such models? 

A: We are still working on this. Our work includes calibration for different technical 
environments (including COOLPLEX). 

Q (Houari): How were the initial values for the weights etc. obtained? 

A: They are similar to those used in Function Points Analysis. However we realize 
that this is a trap. The values are not discriminating enough. 

Q (George): Can the measurement be automated? 

A: Yes. Key classes can be automatically counted. For the other classes we know 
that we need on average 2.5 of them per key class. 

Q (Daniel): Have component object points been checked against object points as used 
in COCOMO II? 

A: Our points are different. The COCOMO object points apply to business objects, 
identified in the early stages of development. Our approach focuses more on the 
system domain. 
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3.3.2 On the Measurement of Event-Based Object-Oriented Conceptual Models 
(Author: Geert Poels) 

Position Abstract 

A suite of measures is presented that addresses two problem areas within 
contemporary object-oriented software measurement, i.e. the lack of measures for the 
early stages of system development, like conceptual modeling, and the lack of 
measures for dynamic models of an object-oriented system. Our suite of measures is 
based on a formally defined object-interaction model, called the object-event table. 
Generally, the objects in a domain are affected by the occurrence of real-world events. 
A framework for measurement is presented that expresses and measures aspects of the 
data, function and dynamic behavior dimensions of a domain, in terms of (common) 
event participations. 

Position Discussion 

This work was presented by Geert and discussed as follows: 

Q (Luis): What about the theoretical validity of the measures? 

A: They have been validated using a specific measurement theoretic structure, i.e. the 
segmentally additive proximity structure. As a result, they are characterised by the 
ratio scale type. A constructive procedure to define measures using this structure was 
presented in last year's workshop. 

Q (Houari): Have the measures been applied to real-time systems? 

A: Not yet. Our main focus of research are information systems, i.e. information 
processing intensive systems. Real-time constraints are not (yet) part of the formal 
model the measures are based on. 

Q (George): Is there any empirical research? 

A: Yes, an initial study has been performed. Results indicate that object-event 
interaction aspects have an impact on understandability, modifiability and 
extensibility of conceptual schemes. However, due to the small scale nature of the 
experiment, most results were not statistically significant. Follow-up experiments are 
planned. 

Q (Daniel): Have you measured other types of dynamic models? 

A: Our project started with the measurement of object-behavioral models like state 
transition diagrams and regular expressions. We have previously proposed measures 
to assess the life cycle complexity of object types. 

3.3.3 A Cognitive Model for Complexity Metrics (Author: Tom Klemola) 

Position Abstract 

Cognition involves both short-term and long-term memories. Understanding how they 
are used can lead to software metrics that predict human performance in software 
development, and can be used to assess and improve the understandability of both text 
and code. Short-term memory is most affected by overloading over a short period of 
time. Long term memory is affected by the frequency and diversity of exposure to a 
concept and degradation over time. Metrics can be defined based on current 
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understanding of both short-term and long-term memory performance to predict 
where and how often errors may occur. 

Position Discussion 

Tom presented his position. This position leaded to the following discussion: 

Q (Luis): Have you looked at applications of cognitive metrics in the web domain? 

A: No, only at the foundational stuff. 

Q (Houari): What is the part of object orientation? Does it lead to more 
comprehensible software? 

A: Object Orientation reduces the number of identifiers in a class and in the class 
methods. According to our theory this should improve cognitive abilities as 
compared to procedural code. On the other hand, 00 introduces additional 
complexities like inherited features, which is not so good. 

Q (Geert): Have you used conservative threshold values instead of averages? 

A: Yes. Simplicity is the goal. 

Q (Fernando): How can expertise and familiarity with a program be assessed? 

A: We look at the portfolio of programs that the programmers have previously 
worked on. That way we identify the patterns or code chunks the programmers are 
familiar with. 

3.3.4 Measuring Object-Oriented Software Architectures from UML Diagrams 
(Authors: Lilli Nenonen, Juha Gustafsson, Jukka Paakki, and A. Inker! 
Verkamo) 

Position Abstract 

The software architecture is the key artifact in software design, describing both the 
static structure and the dynamic behavior of the software. We present our metric tool 
Maisa and its method for automatically analyzing the quality of an architecture. The 
method can be used in an early phase of the software life cycle. Our approach is to 
measure object-oriented architectures from UML diagrams. We also derive quality 
estimates, based on recognized architectural patterns. 

Position Discussion 

Presented by Lilli, this work was discussed as follows: 

Q (Hyoseob): Have you been able to specify the design patterns in PROLOG? 

A: Yes, but some could not be described using such structures. 

Q (Houari): How do you identify the patterns? Are metrics used in this process? 

A: We use structural matching. We match the rules, but do not use metrics here. 

Q and Comment (George): How is this possible. Pattern matching is a notorious 
difficult problem? 

A: We only do a partial matching. 

Q (George): The approach unifies class diagrams. What criteria are used to match 
classes in different diagrams? 
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A: Classes match if they have the same properties. 

Q (Fernando): Why not use a more natural intermediate for UML, like XML? 

A: Our pattern recognition algorithm is based on PROLOG. 

Q (Fernando): What are the driving forces for this type of research? 

A: We work closely with Nokia. For Nokia the size of software is important as it 
must fit into its devices (e.g. mobile phones). 

Q (George): How can patterns be used to predict lines-of-code? 

A: We still have to see to what extent this is possible 



4 Final Discussion Summary 

At the end of the workshop some issues were discussed. These open issues are 
summarized into the following points: 

• The problem of getting industry involved: how to convince industry that metrics 
are important? This requires that the real problems should be identified. 

• A need was identified to share research hypotheses. It was suggested to do this 
based on a questionnaire. Ideally, automatic support is needed (e.g., website). 

• There is a need for measures of non-functional requirements. Why? Answer: 
these take large part of the effort and they have an impact on quality. 

• There is a need for measures that can be applied to component models. 

• An important issue: do we need measures or indicators? In other words, how to 
best use existing metrics and avoid defining new metrics. Part of the answer might 
be meta-metric research 

It is the intent that these issues are communicated in the call for papers of 
WQAOOSE'2001 as special topics of interest. Workshop attendees can work towards 
these topics. It was noted (Fernando) that some of this year's papers addressed issues 
raised at the 1999 workshop, which demonstrates the continuity in this workshop 
series as well as the convergence of research efforts from various teams, 
geographically distributed across Europe and beyond. 
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Abstract. The unrelenting pace of change that confronts contemporary software 
developers compels them to make their applications more configurable, flexi- 
ble, and adaptable. A way to meet such requirements is to use an Adaptive Ob- 
ject-Model (AOM). This paper describes common architectures for adaptive 
object-models and summarizes the results from our ECOOP 2000 workshop. 
Participants to this workshop focused on comparisons between the Adaptive 
Object-Model’i approach and those of Reflection and Metamodeling. It 
emerged that there are common themes present in all three approaches and that 
these approaches can complimen5t one another for assisting developers in de- 
signing and building systems that can more quickly adapt to new and changing 
business requirements. 



What Is an Adaptive Object-Model? 

The era when business rules were buried in code is coming to an end. Today, users 
themselves often seek to dynamically change their business rules without the writing 
of new code. Customers require that systems are built that can adapt more easily to 
changing business needs, that can meet their unique requirements, and can scale to 
large and small installations. 

On the other hand, the same technique is adequate for the slightly different pur- 
pose of producing a whole line of software products: of course, a line of products may 
be obtained by variously instantiating a unique abstract model, but also by adapting a 
given initial system to various requirements that appear simultaneously instead of 
evolving in time. Moreover, the diversification of a successful product may also be 
seen as a form of reengineering. 

Black-box frameworks provided early solutions for the design of flexible im- 
plementation of business rules [3]. Recent research in the different types of architec- 
tures to meet such requirements from an object-oriented perspective has been cata- 
logued as Adaptive Object-Models [1, 2, 5, 13, 16]. An Adaptive Object-Model is 
where the object representation of the domain under study has itself an explicit object 
model (however partial) that is interpreted at run-time. Such an object model can be 
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changed with immediate (but controlled) effect on the system interpreting and running 
it. Note that Adaptive Object-Models usually requires a thorough analysis of the do- 
main at hand, which may very well include a black-box framework as an initial stage. 

Objects have states and respond to events by changing state. The Adaptive Ob- 
ject-Model defines the object model, i.e. the objects, their states, the events, and the 
conditions under which an object changes state, in a way that allows for dynamic 
modification. If you change the object model, the system changes its behavior. For 
example, such a feature makes it easy to integrate a workflow mechanism, which 
proves useful in many systems [4, 11]. 

Adaptive Object-Models successfully confront the need for change by casting in- 
formation like business rules as data rather than code. In this way, it is subject to 
change at runtime. Using objects to model such data and coupling an interpretation 
mechanism to that structure, we obtain a domain-specific language, which allows users 
themselves to change the system following the evolution of their business. 

Metadat^is then often used in adaptive object-models to describe the object 
model itself When runtime descriptions of these objects are available, users can 
directly manipulate these objects. Since the system can interpret the metadata to build 
and manipulate these runtime descriptions, it is easy to add new objects to the adap- 
tive object-model, and make them immediately available to users. This approach has 
been validated by several successful industrial projects [6, 7, 9,1 1,15]. 

Metadata and Adaptive Object-Model workshops at the University of Illinois in 
1998 and at OOPSLA '98 and '99 were devoted to "pattern mining" some of these 
ideas. Our workshop at ECOOP '00 (June 2000 at Cannes in France) was oriented 
toward a broader analysis of the possible uses of the Adaptive Object-Model technol- 
ogy, based on the examination of a range of examples. This paper describes the results 
of the concrete approaches for building dynamically adaptable systems. 



Hot Topics in Adaptive Object-Modeling 

This workshop evolved from the previous workshops held at the University of Illinois 
and OOPSLA. Those workshops had many papers submitted from researchers and 
practioners dealing with issues involving dynamically adaptable systems. This lead to 
the following which is a list of the primary topics that we have been addressing in the 
field of Adaptive Object-Models and which was part of the call for participation to our 
workshop. 



' MetaData can be described by saying that if something is going to vary in a predictable way, 
store the description of the variation in a database so that it is easy to change. In other words, 
if something is going to change a lot, make it easy to change. The problem is that it can be 
hard to figure out what changes, and even if you know what changes then it can be hard to 
figure out how to describe the change in your database. Code is powerful, and it can be hard 
to make your data as powerful as your code without making it as complicated as your code. 
But when you are able to figure out how to do it right, metadata can be incredibly powerful, 
and can decrease your maintenance burden by an order of magnitude, or two. [R. Johnson] 
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1 . Experiences in developing systems, which have been developed with, or might 
have benefited from, an Adaptive Object-Model. 

2. Building a common vocabulary (terminology, definitions, etc,); e.g. Typical 
AI tenninology (ontologies) vs. software engineering terminology 

3. Models and languages for Metadata and AOMs, including current standardi- 
zation efforts and expressive (even ambiguous) type languages,.... 

4. Comparative works with similar approaches like Metamodeling and Reflec- 
tion. 

5. Specific implementation techniques for Adaptive Object-Models. 

6. Design concepts and classification according to semantics and relevance. 

7. Appropriate development process models for cultivating Adaptive Object- 
Models (analysis patterns, design patterns, ...), and the impact of AOMs on 
development process models (iterative, incremental, testing, ...). 

8. How do requirements such as heterogeneous, distributed environments, smart 
software and agents, and user empowerment drive the evolution of Adaptive 
Object-Models? How can we overcome resistance to building Adaptive Ob- 
ject-Models from programmers and managers? 

9. How do get Adaptive Object-Models to exhibit acceptable performance? Can 
we borrow from traditional disciplines, e.g. caching, Just-In-Time compila- 
tion, heuristics, statistics, stereotypical vs. customized interfaces, and tools? 

10. How do measure such aspects of Adaptive Object-Models as stability, class 
library complexity and related metrics, learning curve, cost (development of 
the 'framework', building the applications, change, maintenance), and per- 
formance? 

11. Dealing with views continues to be a challenge; can we use Adaptive Object- 
Models to solve some of these problems? For instance, some models replace a 
hard- wired view on classification of objects by a dynamic view based on ob- 
servational equivalence of object behavior. This view takes into account dy- 
namic properties of the parties involved in a contract. If Adaptive Object- 
Models are any help, which qualities must they possess? 

12. Most Adaptive Object-Model implementations focus on one or two isolated 
aspects, e.g. object model, business rules, mapping objects onto a database. 
Other aspects are typically left to more traditional approaches. Hence, they 
often tend to interfere in ad-hoc and hard-wired ways. For instance, it is often 
hard to design good, pro-active user interface code that is cleanly separated 
from the business rules without introducing redundancy of one sort or another. 
Can we use weaver-like approaches in combination with Adaptive Object- 
Models to achieve more global-wide, yet dynamic reflection? 



Comparative Summary of Contributions 

This workshop brought together researchers and practitioners from a variety of areas 
in order to explore the themes that underlie such systems. Position papers for all work- 
shop participants can be found at http://www-poleia.lip6.fr/~razavi/aom/papers/ . 
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A good sign that a technical area is ripening is that a number of people inde- 
pendently discover it. This would seem to be the case with metadata and AOMs. In 
the main, participants focused on comparisons between the Adaptive Object-Model's 
approach and those of Reflection and Metamodeling. It emerged that indeed all three 
approaches share the same four levels of abstraction. 

The following is a more detailed view of the main positions that were pre- 
sented for participation at the workshop. 



Using AOMs for the Description of Types of Phenomenon over a Period of Time 

Analysis Patterns are solutions to recurrent problems in modeling a problem domain. 
However, analysis patterns are not necessarily easy to implement. We have developed 
several applications that capture medical observations about patients using the Ob- 
server pattern. This paper [9] describes how we dealt with problems while evolving 
from analysis to design, how we extended the Observation pattern to work in our envi- 
ronment, and the details of how we implemented this pattern. This is a very good 
example of using Adaptive Object-Models to allow end-users to dynamically custom- 
ize their system without needing to write new code. 



Using AOMs for Building Flow-Independent End-User Programming Systems 

The goal of end-user-driven application development is to provide end users with 
greater computational power to create, customize and extend their software. 

Adaptive Object-Model architectural style is particularly adequate for build- 
ing end-user programming systems. By providing design patterns to create dynami- 
cally adaptable systems, they offer an appropriate foundation to the problem of facili- 
tating programming for end users and domain experts. 

However, creating flow-independent [4] end-user programming systems in 
the context of Adaptive Object-Models is still a problem. 

Type Cube [14], as shown in Fig-1, is a model that addresses this problem by 
coupling micro-workflow [4] and the core of Adaptive Object-Models [6, 7]. It pro- 
vides guidelines for designing object-oriented applications that can be extended and 
personalized by dynamic definition of new entity types and processes. This design 
work can be done by domain experts. Type Cube has been validated by two industrial 
projects. 
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Fig-1. T5^pe Cube Model building flow-independent end-user programming systems. 



AOMs for Building Data Warehouse and Business Intelligence Environments 

The Common Warehouse Metamodel (CWM) is a recently adopted standard of the 
Object Management Group (OMG) for metadata interchange in the data warehouse 
and business intelligence environments. CWM extends the OMG's standard 
MOF/UML/XMI metamodeling architecture with data warehousing and business 
intelligence domain concepts. CWM supports a model-driven approach to metadata 
interchange, in which object models representing shared metadata are constructed 
according to the specifications of the CWM metamodel. Tools agree on fundamental 
domain concepts (as defined by the CWM metamodel) and, therefore, are capable of 
understanding a wide range of models representing particular metadata instances. 

We believe that the OMG architecture (in particular, the MOF ontology, 
meta-layer stack, and semantics imposed on compliant metamodels) generally allows 
for the creation of metamodels whose instances readily align with (or reveal or ex- 
pose) the fundamental patterns of Adaptive Object-Models. The CWM metamodel, by 
directly extending MOF/UML, drives support for Adaptive Object-Model patterns 
into the data warehousing and business intelligence domains, leading the way for a 
new generation of data warehousing and business intelligence tools that are dynami- 
cally configurable and highly adaptive to changing environments. Such tools would 
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be driven by Adaptive Object-Models, with CWM serving as the foundational meta- 
model guiding the creation of those Adaptive Object-Models. 



Support for Adaptive Workflow (CRISTAL Project at CERN, Geneva) 

The current trend in software engineering is towards developing complex systems for 
use by growing and changing communities of users that require access to large-scale 
data repositories or data warehouses. Inherent in the approach to designing such sys- 
tems is the ability for systems to cope with changing user requirements, to be inter- 
operable with existing (legacy) systems, to handle multiple versions of reusable code 
and to be configurable as needs evolve. One approach that is gaining favor is to de- 
velop systems that are Description-driven [12] i.e. that not only handle and allow 
manipulation of data objects but also objects that capture system description. 



Using AOMs for Content Management Transactions 

Another domain where Adaptive Object-Models have been identified is form-database 
interaction in a content management system. Handles for read/write database state- 
ments have properties, strategies and can be implemented as type objects [10]. 

An additional complication, which came up in this application, was the need 
for a transaction manager to orchestrate the interaction of individual objects, which 
raised the question of how to formalize different pathways through a tree of interde- 
pendencies. 



Summary of Discussions 

A majority of participants observed that Adaptive Object-Modeling, Metamodeling 
and Reflection share the same dimensions of abstractions as shown in Fig-2. The top 
most level, called L3, represents a language for describing languages. The next level, 
L2, represents a domain specific language, derived by applying L3 to the application 
domain. The LI level represents the specification for a particular software (system). 
Finally, the LO level represents is an instance of that specification. 

Type Cube (Fig. 1) is an example of this conceptual layering from Adaptive 
Object-Modeling. Applying Type Cube to an application domain delivers an adaptive 
object-model-based domain specific language for that domain. This language allows 
experts to specify their applications, which are then instantly executable. 

The Reflection community has also used similar approaches to provide adapt- 
able programming languages. Many reflection techniques can be found in Adaptive 
Object-Models. 

The Common Warehouse Metamodel (CWM) is another example from Meta- 
modeling , that has already adopted this four level architecture. In fact, the MOF on- 
tology, meta-layer stack, and semantics is imposed on compliant metamodels. 
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Fig-2. Dimensions of abstraction in AOMs, Reflection and OMG ’s metamodeling Architecture. 



CWM extends the OMG's standard MOF/UML/XMI metamodeling architec- 
ture with data warehousing and business intelligence domain concepts. CWM sup- 
ports a model-driven approach to metadata interchange, in which object models repre- 
senting shared metadata are constructed according to the specifications of the CWM 
metamodel. Tools agree on fundamental domain concepts (as defined by the CWM 
metamodel) and, therefore, are capable of understanding a wide range of models rep- 
resenting particular metadata instances. 

The OMG architecture generally allows for the creation of metamodels whose 
instances readily align with (or reveal or expose) the fundamental patterns of Adaptive 
Object-Models. The CWM metamodel, by directly extending MOF/UML, drives sup- 
port for Adaptive Object-Model patterns into the data warehousing and business intel- 
ligence domains, leading the way for a new generation of data warehousing and busi- 
ness intelligence tools that are dynamically configurable and highly adaptive to 
changing environments. Such tools would be driven by Adaptive Object-Models, with 
CWM serving as the foundational metamodel guiding the creation of those Adaptive 
Object-Models. 



Conclusions 

A dominant theme was that the need to confront change is forcing system architects to 
find ways to allow their systems and users to more effectively keep pace with these 
changes. A way to do this is to cast infonnation like business rules as data rather than 
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code, so that it is subject to change at runtime. When such data are reflected as ob- 
jects, these objects can, in time, come to constitute a domain-specific language, which 
allows users themselves to change the system as business needs dictate. 

A major accomplishment of this workshop was to finally get this disparate 
group together, and to establish this dialog. However, we’ve only begun the task of 
fleshing out these architectural issues, uncovering the patterns, and of better defining 
our vocabulary. It was noted that principles of Reflection and MOF could be used to 
better support the goals of AOMs and vice-versa. We are looking forward to recon- 
vening the members of this community to continue this work. The focus of the next 
meeting will be around on seeing where these communities meet and how they can 
support one another for achieving the goal of building dynamically adaptable systems. 
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Abstract. The purpose of the workshop was to bring together research- 
ers and practitioners from academia and industry to report on their 
experiences with developing precise semantics for the UML. This one- 
day workshop was the 4th of a successful series on strengthening the 
UML semantic foundation. Presentations and discussions have focused 
on identifying the challenges, recognizing limitations, and analyzing pro- 
posed semantics for the UML. The workshop was organized by the precise 
UML group (pUMlQ). 



1 Introduction 

Context 

The Unified Modeling Language (UML) is the OMG (Object Management 
Group) standard modeling language for specifying and designing complex soft- 
ware systems. The high quality experiences embedded in the UML certainly 
makes its application to complex systems desirable, but the lack of precise se- 
mantics can limit its effectiveness. 

The modeling of complex systems requires the use of modeling constructs 
that provide complexity management mechanisms and that allow early detec- 
tion of errors in requirements and designs. The separation of views principle has 
proven to be an effective means of controlling complexity, and is well-supported 
by the UML. However, the formality and rigor principle that facilitates the de- 
tection of errors in requirements and designs is not well-supported in the UML. 
Developing a precise, complete, and understandable semantics for UML that 
enables practical, tool-supported rigorous analysis of UML models can enhance 
its applicability to the modeling of complex systems. A formal analysis of the 
semantic foundations of the UML notations can lead to more precise and com- 
plete natural language descriptions of the notations in the UML standard. The 
insights provided by a well-formulated description of the UML semantics can 
help modelers choose appropriately among a variety of modeling constructs. 

* See URL: http://www.cs.york.ac.uk/puml/. 

J. Malenfant, S. Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 113- 11221 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 
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Overall Plan of the Day 

After the classical opening remarks, four of the submitted papers have been pre- 
sented [1,4,11,19]. Then after the first break, the audience has been divided into 
groups discussions. The submitted position papers had been previously grouped 
into 4 groups of interest: 

1. Behavioral model [3, 4, 20, 7] 

2. Precise semantics [6, 10, 11, 15, 16, 18, 19] 

3. Static models [2, 5, 7, 8, 9, 17] 

4. Metamodel [1, 12, 13, 14, 19] 

Due to the fact that not all the submitters were attending the workshop and 
that few attendees were not submitters, it turned out that the groups on precise 
semantics and on static models were grouped together. 

After the lunch and the second round of discussions the groups leader pre- 
sented some slides summarizing the discussions and the remaining sections of 
this report draws the main topics that have been discussed among the groups. 
Sections 2 to 4 are dealing with the main discussions of the four groups. We 
conclude in section 5 by summarizing the discussions and by providing some of 
the main results of these discussions in terms of the future of precise semantics 
for UML. 

2 Behavioral Model 

There were 4 position papers that were categorized as belonging to the behavioral 
group. 

[3] and [7] both discuss the formalization of UML Statecharts. The work of [3] 
proposes to reengineer the UML metamodel to facilitate the formalization, while 
the paper by [7] discusses a concrete formalization of the UML Statecharts using 
Isabelle. The main problem raised in both papers is the problem of reasoning 
about the interaction between Statecharts and Class diagrams. The two other 
papers of the working-group [20,4] discuss the semantics of sequence and collab- 
oration diagrams respectively. In [20] some problems that arise when creating 
Statecharts from sequence diagrams are discussed. Finally the authors of [4], who 
did not participate in the discussion, propose a formalization of Collaboration 
Diagrams using the Object-Z language. 

The common thread of the 3 papers [3,7,20] is to try to understand the 
relationship between the different behavioral models (Statecharts, Sequence Di- 
agrams, and Class Diagrams). The participants identified the ability to relate 
meanings of these diagrams as one of the criteria that any formalization of the 
UML has to satisfy. 

After a short presentation of the papers, the participants tried to identify 
a number of questions to discuss. Due to lack of time the discussion mainly 
centered around the rationale behind each question. 




Defining Precise Semantics for UML 



115 



If the UML Metamodel is to be reengineered, then what should form its core? 
The UML standard defines 3 diagram type^ that we consider to belong 
to the behavioral sublanguage: 1. Statecharts, 2. Collaboration diagrams, 
3. Sequence diagrams. The UML standard identifies a number of common 
concepts for these diagrams that are grouped into the Common Behavior 
package. These are signals, actions, instances and links. From a semantical 
point of view it is strange that the notion of a state has not been included 
in the Common Behavior package. A state is a fundamental concept in any 
behavioral formalism. Therefore the discussion centered around the idea pro- 
posed in [3] to define a new core package for the Behavioral elements that 
views State as a fundamental concept and relates the other behavioral con- 
cepts in relation to state. 

How should the behavioral diagrams be related? This question was discussed 
together with the previous question. It was found that the easiest way to 
relate the behavioral diagrams is through the common notion of state. 

How should the behavioral models be integrated with class diagrams? In UML 
it is possible to describe behavior in two ways: through UML Statecharts and 
methods in class diagrams. It is easy to see that there can be interactions 
between these two entities that affect the behavior of the whole system. 
To achieve accurate verification results it is thus important to have a well 
defined integration of the behavioral and static parts of the UML. 

Do verification, simulation, and code-generation have different requirements 
for the formalization? Verification, simulation and code-generation clearly 
have different goals. For verification it is important to be able to do ab- 
stractions so that the verification of large state-spaces becomes possible. On 
the other hand, for simulation and code-generation the formalization must 
be as accurate as possible. Finally for code-generation one may have extra 
requirements like optimizations for time or space. On the other hand, to be 
able to compare these semantics some kind of reference semantics is clearly 
needed. 

How should a formalization deal with the creation and destruction of objects? 
Creation and destruction of objects poses a problem because they change 
the structure of the system. At the moment a collaboration diagram is a 
static picture of the system. It should be extended to reflect the execution 
of a new or delete action in an object. 

What is the relation between the entities Signal, Action, Event, Message, and 
Operation? The current behavioral core defines a number of concepts that 
are very similar but are used in different contexts. The relationships between 
these should be clarified. One would expect that the approach proposed 
in the first question would define the relationships among these concepts 
exactly. 

What is an appropriate notation for defining the semantics? The final question 
may be the most difficult to answer, mainly because there are so many 
proposals available. Although we all agreed on the need for some kind of 

^ The activity graphs have not been considered during the discussion. 
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reference semantics, the participants decided not to take a stand on this 
question. 



3 Precise Semantics 

The main concern for this discussion group has been held by the following 
thought: we are now working for some time at trying to provide a more pre- 
cise semantics for UML and though (i) we are all doing our little piece of work 
on our side; (ii) there is little concern from the OMG, who leads the future of 
the UML, in this area of development; (iii) there is no evidence in the head of a 
lot of practitioners that there is a need for precision within the UML. This led 
us to focus on the main following questions. 



How Can We Get OMG Interest? 

In order to have a precise semantics for the UML we need to let them know as 
much as possible the number of efforts and proposals that are published around 
that area. Even more important, we need to convince the members of the OMG 
that it is a useful effort. Finally we need to have enough members of the OMG 
voters in favor of this issue. 

One way of getting OMG interest is by submitting reporting issues. The 
OMG has a complete review process for issues. Although they receive a lot of 
such issues, it is a worthwhile effort, especially with the support of some of the 
members themselves (the number of pUML members who become members of 
the OMG is growing significantly). 

Finally, we need to make more explicit and widely known the ambiguities, 
problems, etc. encountered in the use of UML, and which are due to the lack of 
precisely defined semantic (set up a repository for ambiguities examples, things 
that cannot be done in UML, use of XMI support, need for classification). Al- 
though some efforts have been made in this arerOl real examples would illustrate 
better the need for preciseness. 



Gan We Define a Glassification for the Different Approaches? 

It is necessary to get OMG support in giving a precise semantic to the UML. But 
in order to get a successful process, we need to make sure that the RFP will pass 
the voting process. And for this we need a collaborative, joint effort. So far people 
working in this area have little interactions although the success of the three 
previous workshops lead us to think that there is a true will for collaborative 
efforts. So may be one of the first step will be to be able to evaluate the several 
contributions around precise semantics in order to point out the differences and 
commonalities between them. 

At a first glance, a taxonomy of the different approaches that can exist seems 
hard to define. The main reason is the number of different directions in which 

See the URL: http://cgi.omg.org/issues/uinl-rtf.html. 
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you can analyze a contribution. So our discussions led instead in a set of criteria 
that a submitter would have to fill in order to characterize its proposed approach. 
So we end up with a set of questions and choices, writing them in terms of a web 
page form (see fig. [T|). Our intention is to maintain a web page containing the 
form and associated with a database, allowing us to do a survey of the existing 
approaches by asking people from the community to fill the form, give little 
details on their approach, as long as links and primary contact email address. 




Fig. 1. An example of ontology 



Here are the questions that we have defined during the discussions. This list 
is not at all complete, and will be hopefully enriched by discussions through the 
pUML mailing list. 

— Formalization Computer Support 

• Assisted 

• Unassisted 
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— Formalization Process 

• Direct 

• Transitional 

* Sequential 

* Parallel Successive Refinement 

— Formalization Feature Support 

• Composition 

* Intra-diagram 

* Inter-diagram 

* Tool/diagramatic support for chosen compositional method (tool) 

• Refinement (what do you refine) Model Check 

• Model/ Axiomatic Approach 

• Modular (how) 

• ... 

— Formalization Structure 

• Underlying Model 

• Math Foundation 

• Language Support 

• Number of Layers of Metamodel 

• ... 

— Formalization Strategy 

• Strategy 

* Restriction (subsets, ...) 

* Extension (profiles, prefaces, ...) 

• Iterative (process) 

• Workflows (language) 

• ... 

— Formalization Outputs (Validation, code generation, improving UML effi- 
cacy, ...) 

• Goals 

• Results 



How Can We Improve the pUML Approach? 

In this point we have discussed how we could improve our own way of working 
at the semantics improvement. It has been decided to set up a repository of 
the discussions in the pUML list (re-factoring the list into a web based process 
for example, etc.). Subgroups will also be identified in order to focus on more 
precise aspects of this wide area. Progress in this goal can be followed by checking 
regularly the pUML web site. 
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4 Metamodel 

The first round table of this discussion group quickly led to the three following 
main topics: 

~ What is the Mate-level for (and as a subsidiary question: What features 
should a meta-level have)? 

— What formalism for Meta-Modelling? 

— What design principles for the MOF? 

These questions and the corresponding answers are detailed in the following 
sections. 



What Is the Meta-level for? 

As an answer, we can say: “To define building blocks for abstract/concrete syntax 
and precise, unambiguous semantics for UML” . 

The group has then identified the users of the meta-level: 

— tool builders (instanciation, verification) 

— methodologists (new concepts) 

— profile builders (sublanguage, language extensions, semantic variation, spe- 
cial notations) 

— meta modelers (modification, query) 



Meta-modelling Formalisms 

At this point the group has examined particular formalisms 

— B: experience suggests that it is well adapted for functional properties, spe- 
cific domains, that it supports proof, but that it is not well adapted to 
behaviours and that expert user are required. 

— Z/Object-Z: is more general than B, may be too general. 

— ASM: provides support for both static and dynamic aspects, but tool support 
is perhaps a little immature. 

— OCL: is included in UML, but, has no semantics or tool support. 

As a conclusion the requirements for Meta-modelling formalism is that it 
must effectively describe dynamic behaviors and supports the flexibility of proof- 
like systems. The meta-model properties: 

— simple definition of UML, 

— orthogonality between MM features, 

— allows the definition of a precise semantics of UML, 

— reuse, inheritance of features, 

— machine readable / human understandable. 
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Design Principles for MOF 

The conclusions of the discussions on this particular topic were : 

— problems in the UML are not caused by the MOF, 

— fixing MOF may make UML fixing easier, 

— MOF needs to be changed due to the 4 layer architecture (we cannot refine 
the existing MOF into a better MOF’), 

— the 4 layers architecture is unnecessarily restrictive, 

— MOF needs to be precise, 

— UML could be based on a loose MOF (UML semantics would add con- 
straints) 

5 Conclusion 

It is evident that a single semantics and concrete syntax for the UML will not 
suffice. The challenge is to restructure the UML in such a way to facilitate 
graceful evolution and to provide high-level extension mechanisms that facilitate 
disciplined development of precise modeling languages. A suggested approach is 
to base UML language extensions on a core set of UML notations. 

This workshop is one of a series of workshops on strengthening the UML 
semantic foundation. The first workshops focused primarily on the utility of 
having precise semantics. This workshop focused on identifying appropriate se- 
mantic foundations for the UML. The next step will focus on approaches to 
refactoring the UML to make it more precise and evolvabl^fl 
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Abstract. Classification is a central concept in object-oriented ap- 
proaches such as object-oriented programming, object-oriented knowl- 
edge representation systems (including description logics), object-orien- 
ted databases, software engineering and information retrieval. 
Nevertheless, research works on classification have often been carried out 
separately within these different approaches, and they have not always 
been precisely confronted and connected. The goal of the workshop was 
to confront these complementary viewpoints on classification, to exhibit 
and discuss commonalities and differences within these approaches. 



1 Introduction 

Object-oriented approaches are mainly based on a proximity between real world 
entities and their computer representation. This leads primarily to the well 
known “classes”[3, “instances”, and specialization relationships implemented by 
inheritance. More generally, a common trend in object-orientation is to reify 
all the considered items, and classify them. Unfortunately, research works that 
deal with classification in object-oriented approaches are spread over different 
fields such as object-oriented programming, object-oriented knowledge represen- 
tation systems (including description logics IHBEI]), object-oriented databases, 
software engineering and information retrieval [El El- Furthermore, they are con- 
cerned by various entities like use cases, classes, prototypes, methods, patterns, 
and they have different goals, like designing, reasoning, indexing and program- 
ming. Due to these differencies, many research works are carried out separately, 
although they have a common concern. 

The workshop intended to put together and to confront all these complemen- 
tary viewpoints on classification, in order to bring on the foreground common 
questions, and to provide a basis to discuss and share classification techniques. 

^ When ambiguous, denoted by oo-classes for “classes in object-oriented systems”. 
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This document reports and synthetizes the contributions (position papers 
and discussions) with regard to the following points: 

— main trends of the workshop, 

— definitions of classification (as “classification” is polymorphic) , 

— objectives followed in the classification process, 

— classified entities, 

— context of the classification (relatively to the life-cycle of the software), 

— structure of the classifications produced (partitions, trees, lattices, etc.), 

— systems, tools, techniques in general. 

2 An Overview of the Contributions 

The workshop was appropriately introduced by [wlOJ . which recalled the Aris- 
totle’s ideas on classification and how they concern object-oriented approaches: 
either because they are already present although hidden, or because they could 
be beneficial. 

Apart this first contribution, two main trends were represented. 

The first, or “software classification”, is concerned with classification prob- 
lems applied to software engineering. It not only aims at managing classes and 
hierarchies, but it also extends the notion of classification to all software arti- 
facts: 00 -class hierarchy evolution |w9| . reuse of persistent instances [w3J . tagging 
software |w5j . logic predicates for reasoning on the software |w7j or generating 
code |wl2J. use case management [w m. 

The second trend is closer to knowledge representation concerns. It focuses 
more on the notion of oo-class hierarchy, develops specific models (classes de- 
scribed by disjunctions | w8| . prototypes a UML-like model |w4| . graphs 
|w2l Iw6p . and techniques as instance classification |w8l Iw4| . conceptual cluster- 
ing [w2L Iwl 3 1 IwBj , or genetic algorithms |w1 1] . 

3 The Meaning of “Classification” 

The term “classification” usually covers both the process and the result of: 

— class discovery 

• either by dividing a set of entities; classes obtained in this way can be 
called “extensional classes”; pure extensional classes (sets) are rather 
uncommon in object-oriented approach; 

• or by associating a description to a set of entities; these classes are “in- 
tensional classes” ; in this case, the intension can be given either a priori, 
for example by a human actor from his knowledge of the domain, or a 
posteriori, when it is deduced from the analysis of a set of objects. Such 
intensional classes also have an extensional counterpart: the objects cre- 
ated from or covered by the intension. 

— class organization ( “class classification” ) into specialization structures (trees, 
lattices, etc.), 

— associating a class to an entity (“entity/instance classification”). 
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The difference between extensional and intensional classes is pointed out and 
discussed in |w7| . Even in data analysis BUZ], which is more interested in the 
extensions, the classes are described by “numerical structures” (line, hyperplane, 
etc.) that can be considered as their intension, although interpretating this in- 
tension is not obvious. 

Intensional and extensional classifications are intimately related. Gather en- 
tities in a set to produce an extensional class implies tagging these entities by 
their membership to that class. The different tags resulting from the different 
memberships of an entity can be used as a description of this entity. Intensional 
classes can then be built according to these descriptions, having an extension 
which may be different from the initial extensional classes, etc. 

Let us detail how these different meanings of classification appear in the 
contributions. 



Oo-Classes. Oo-classes are essentially intensional classes. In object-oriented 
modeling and programming, they are traditionally defined a priori, with their 
extension mostly derived at running stage. This is usually done “manually”, 
but techniques for a posteriori class discovery and organization also exist and 
were represented at the workshop. In the context of programming languages, 
|wH] deals with local class hierarchy modification by adding “interclasses” . |wi:i] 
compares two common clustering techniques, similarity-based clustering tech- 
niques and the Galois lattice approach. The debate on techniques for a posteriori 
class discovery was broadened out by two contributions [Iw21 Iwbj relative to the 
generalization of classes described by a graph-based language. 



Instances. When instances are not created from an oo-class, as for example 
in object-oriented representation systems, instance classification is a main prob- 
lem. Interesting variants of instance classification methods have been highlighted 
during the workshop, in the context of classes described by disjunctions |wS| . or 
in a UML-like model where classes and associations coexist [lw4J . The approach 
of [wlllj exploits instance classification to guide emergence of new classes, in a 
context where instances may evolve independently of classes. Such a method 
may admit classes defined a priori and promotes classes discovered a posteri- 
ori. Another original problem relative to instance classification is using a set of 
(persistent) instances with different (although related) class hierarchies [Iwbj . In 
this work, accurate descriptions of the relationships between classes are used to 
guide the loading of persistent instances by an application (this loading has to 
be understood as instance classification). 



Prototypes. It was shown in that, in the framework of prototype-based 
languages, “class-less” in essence, there is also a need to define generalizations 
(abstractions). The ambiguity that exists, in some of these languages, among 
concrete individual, prototypical individual and kind of classes (trait), results 
in more flexible language constructions that could help classification processes. 
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The meaning of classification in prototype-based languages is roughly similar to 
the corresponding problem in class-based languages, only minor variations were 
reported and the topic is still to be explored. 



Software Artifacts. In “software classification” |w51 |w III w two main clas- 

sifications are mentioned: “manual classification” , which consists in putting to- 
gether software artifacts manually, and creates extensional classes 1^; “virtual 
classification” where classes are intensional. The intension can be represented 
either by a logic predicate I w 121, or by tags |lw5| . The classes are mainly 

defined a priori, with their extension often computed from the intension. 

The possibility of improving software classifications by the organization of 
software artifact classes has been discussed. Criteria like inclusion of the ex- 
tensions, or specialization between intensions (implication between the logic 
predicates associated to the artifact classes, for example) could be used. The 
techniques mentioned in [w1 SIJ . that are not restricted to the oo-classes produc- 
tion and organization, could help such a classification process and produce more 
elaborated artifact classifications. 

The table [T] gives a (subjective) overview of the contributions regarding the 
classification meaning (x-|- in the first row corresponds to works where exten- 
sional classes are also mentioned or used). 
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Table 1. Use of classification meanings 



4 Objectives of Classification 

As reported by |w1 Oj . classification (one form of “division” for Aristotle) is part 
of the process of understanding and reasoning. This section shows how, replaced 
in the framework of object-oriented approaches, these general assertions become 
more concrete, and how some are more specifically related with software engi- 
neering, while others are characteristic of object-oriented knowledge representa- 
tion. 



Design. Design in object-oriented approaches is concerned with producing a 
model of the domain: oo-classes represent “concepts of the domain” (groups of 
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objects that share a common behavior and structure); specialization hierarchies 
more or less reflect complex concept classiflcations; other entities (states, dy- 
namic diagrams, design patterns, etc.) are concerned with dynamic aspects or 
high-level modeling. In software engineeering, all design methods give accurate 
guidelines to build specialization hierarchies, as for example OMT or the 
UML formalism [^. 

Many contributions are concerned with design. For |w2(lwfiLlw1 M] the problem 
is clearly to organize knowledge by clustering or generalization techniques. A 
proposal of [S| is to use prototypes at the design stage, to facilitate the process 
of abstraction discovery. When the domain description appears to be stabilized, 
an 00 -classes hierarchy can be generated. Software classiflcations, that help the 
detection of high-level informations such as object collaborations, components 
|w5] or even design patterns, also play a role in improving the domain model. 

Providing a model of the domain is a concern that goes beyond the design 
step, especially because the domain, or our understanding may evolve. |wll| 
approaches this problem, describing an oo-class evolution based on instance evo- 
lution, that is, at run-time. The proposal of |w9| is in a same evolution perspec- 
tive, but limited to the code (note that this code is supposed in use), and it 
proposes an “interclassing” technique to adjust the class hierarchy to some local 
evolutions (for example, methods or classes become deprecated — out of date — 
or the behavior of a class is slightly changed). 



Storage, Inspection, and Recovery. A main point in |w5L Iw7l Iwl4] is to 
index, browse and query large collections of software artifacts, like oo-classes, 
methods, use cases, etc. 

Another issue is related to persistence and reusability |wd) : persistent objects 
have to be reusable! Classification may be used to improve these two related 
aspects of object-oriented programming (organizing and indexing persistent ob- 
jects). 



Programming. In the framework of software engineering, the encoding in a 
programming language of the oo-class hierarchy gives a basis for programming. 
Some parts may be generated automatically, for example, most software devel- 
opment tools generate part of the class code directly from design diagrams, al- 
though method bodies cannot be generated in the same way. Another approach 
is, like in [w1 2| . to define a classification of some artifacts that is used after- 
wards to generate code (for example add a specific code to all classes verifying 
a predicate). The proposal in jw9] has also to be considered as a help for the 
programming step. The problem of interclassing is to build a superclass instead 
of a subclass, and a consequent question is: how interclassing can complement 
subclassing for code organization? Last but not least, classification appears to 
be useful in order to improve code factorization mm- 
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Software Architecture Control. [w7lj shows the interest of virtual software 
classifications in checking the compliance between a software architecture and 
its implementation, and in keeping detected abstractions on the software syn- 
chronized with the code. 



Software Running. After encoding in a programming language, some dynamic 
aspects (as method calls) are supported by the classification (in this context 
the inheritance hierarchy). In |w3| . the problem is really to use a classification 
mechanism to run an application on persistent instances that may have been 
generated by another application with different classes. 



Reasoning, Predicting. In the software engineering context, the virtual classi- 
fications of | w7| . as they are expressed in a logic language, are used for reasoning 
on the software architecture. Apart this aspect, reasoning is more the purpose 
of object-oriented knowledge representation systems. 

With regard to reasoning, problems are to understand how classification can 
be a basic tool for inferencing, and to enlighten the different relations existing be- 
tween the different formalisms for representing knowledge and solving problems 
using classification, object-oriented knowledge representation and description 
logics are examples of such representation and reasoning formalisms. Instance 
classification [w4l Iw8j allows for example to deduce instance features (most of 
the time the value of an attribute). 

5 Entities under Classification 

Many entities are candidate for a classification process. They can be divided 
among: 

— a structural viewpoint (“object” in a broad meaning, that is, instances, 
classes, prototypes; features as attributes and operations, associations, ob- 
ject states), 

— a dynamic viewpoint (events, changes of state, actions, interactions). 

And as we have seen before, classification may be in concern with: 

— “objects” (always in a broad meaning), described by their structural and 
dynamic features, 

— the other entities (operations, associations, state diagrams, collaboration di- 
agrams, use cases, etc.). 

5.1 Entities 

’’Objects”. Many contributions deal with “object” classification. Two main 
models, stemming from cognitive science were discussed: the class-based model 
and the prototype-based model. For the class-based model, a concept is described 
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by an “extension” (set of concrete examples) and an “intension” (set of features). 
Objects may have two different status, instance or class status (an object that 
has the class status may also be instance of another class, usually called its meta- 
class). For the prototype-based model, a concept is described by reference to a 
special object, namely the prototype. The class-based model may be considered 
as more complex because each object may have two roles (instance or concrete 
object/class or abstract object), and there are two different abstraction mech- 
anisms (instanciation and specialization). By contrast, in the prototype-based 
model, there is only one status for the objects, and they are, in a first approxima- 
tion, related by only one relation, “is-extension-of” , that supports the delegation 
mechanism. Nevertheless this last model suffers from several problems (identity 
and organization) that are differently solved in languages. An important discus- 
sion based on the presentation of [wllj was that it would be worthwhile to look 
at “hybrid” languages that unify and integrate the benefits of prototype-based 
and class-based languages in a seamless way. The Agora language |2Hl[2n] is an 
example of such a hybrid system. 

Software Artifacts. Software classification |w5L Iw7( Iwl 21 Kvl 4J is potentially 
concerned by all entities (classes, methods, etc.), and gives views on the soft- 
ware not limited to a specialization (or inheritance in the programming case) 
hierarchy on oo-classes. Actually, this trend, that has some links with aspect- 
oriented programming, generalizes the impact of classification in object-oriented 
approaches. In particular, conceptual clustering techniques applied to code ab- 
stractions could lead to the automatic discovery of “aspects” . 

Other useful references on software classification are [21 E3I, ng. 

5.2 Description Language 

We inspect now in more detail the “language” used to describe entities under 
classification, and the language used to describe classes if it is different. It is 
useful to warn the reader that this notion of “description language” is not always 
well codifyed. 

Objects/Prototypes/Oo-Classes. They are mainly described by a conjunc- 
tion of features, among which there are always attributes, sometimes with a type 
— a range — (mainly in oo-classes) or a value (mainly in concrete objects |w1 8j ). 
The presence of methods among features is more usual in the programming ap- 
proaches. Methods are in the center of the problem for [w9J . being the cause 
or the solution of the modification; they are present in the model of jwS] and 
may be used for the loading of an instance (if we consider that a method can 
be called in the invariant of a class); they are mentioned, but not discussed in 
|w1 1 ] . They are also considered in class-construction algorithms [THl Ej which 
were mentioned during the discussions. 

In a more prospective approach, [w8J has shown that it can be sometimes 
convenient to introduce disjunctions in the class description to describe the vari- 
ability of objects within the same classes (individuals and natural kinds). This 
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is actually the case in the so-called semi-structured classes and semi-structured 
objects. Moreover, links can be made with polythetic classes where a class is 
defined with respect to a set of attributes that are shared by the objects j27ll30| : 
the attributes are not necessarily all possessed by the members of the class, and a 
class is no more defined by a defined set of attributes acting as a set of necessary 
and sufficient conditions for an object to be a member of the class. 

Another trend, close to instance and class diagrams in the UML formalism, 
is to represent objects provided with their features and associations. First, this 
leads to a model like in |w4j . second this tends to consider objects described by 
graphs. Methods using such a representation have been proposed in [w2LlwtiJ . and 
|w6) has tried to fill the gap between theoretical aspects and pratice, searching 
for a graph model appropriate in the object-oriented context. 

An interesting point was to make a distinction about the nature (significance) 
of object features. [w1 Oj reports the Aristotle’s division among properties and 
accidents. In |wllj . there is a notion of “fundamental genotype”, that covers the 
set of “minimal and fundamental features inherent to a population” , by contrast 
to features specific to classes in a population. 



Software Artifacts. A first proposal for software artifacts is to attach to them 
a collection of tags Iw5l in order to index and query the artifacts. These tags are 
included by the developpers in the source code. A tag has a name and a value, 
that can be a string or a number. 

In another approach | |w7llwl2| . software artifacts are described by their code, 
and classification is done by logic predicates on the code. These logic predicates 
are abstractions on the software and can be interpreted as a kind of declarative 
approach to code manipulation. 

For use cases, the description is a tricky problem knowing that they are 

given in a somewhat unstructured manner based on natural language, that is am- 
biguous by nature. The use case management can be enhanced when an ontology 
of the domain related to the use cases is available, i.e. a kind of knowledge-based 
approach to use case management. 

Returning to UML diagrams, as they are in essence labelled graphs, a ques- 
tion is to exploit results of |w2llwfij to have a way of generalizing them, producing 
patterns of event sequence, collaboration, state change, etc. 



6 Classification Context 

The previous sections made clear that classification is related to all the main 
steps of the software life-cycle: 

— Analysis, for example with use cases [lwl4J . 

— Design, design of oo-class hierarchies 1^, or design of artifacts in general 




— Implementation, when classification serves as a guide for encoding [wHllwl2] . 
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— Exploitation (run-time), where the computation [w3j or the reasoning |w81 

Iw4| are based on instances. 

It appears also that a main common topic of interest is evolution. This is 
for example the case with “automatic class hierarchy reorganization” Iwll . “ex- 
ploiting classification for software evolution” Iw5l . using conformance checking 
for managing co-evolution between an architecture and the software code to deal 
with architectural drift and software erosion hierarchy evolution Iw9l . “Ob- 
ject Structures Emergence” Iwlll . etc. A difference between the approaches is 
that the artifact-based software classification approach deals more with design- 
time evolution, while the object-oriented classification problematics is present in 
all steps. 

7 Forms of Classifications 

7.1 Classification Structures 

The simplest form of classification structure is an unrelated collection of sets. 
This is the case in artifact-based software classification |w5l Iw7| . As said before, 
an issue was to see if it could be useful to compare and organize these sets simply 
by inclusion, or to apply conceptual clustering techniques to these sets. 

However, most of the contributions deal with hierarchies, whose structure 
is a tree |w4| . a lattice |w2l [w m w m, or any partial order |wll Iw3l Kv8| . This 
variety is reflected in languages, some of them admitting multiple inheritance 
(C-|— b, Eiffel), others only single inheritance (Smalltalk). Java has a special pol- 
icy concerning this point: it admits two kinds of concepts, classes and interfaces, 
with single inheritance for classes and multiple inheritance for interfaces. 

The viewpoint of Aristotle’s is the following |wlO| . The division must be 
exhaustive, with parts mutually exclusive, and an undirect consequence of Aris- 
totle’s principles is that only leaves of the hierarchy should have instances. Fur- 
thermore, the divisions must be based on a common concern (the discriminator 
in UML). This is not always the case in usual programming practice. Multi- 
ple inheritance, for example, is contradictory with the assumption of mutually 
exclusive parts, and instances may in general be directly created from all (non- 
abstract) classes. Direct subclasses of a class can be derived according to different 
needs (for example [2S], a class Employee can be specialized at the next level 
by classes that distinguish the status — first discriminator — mixed with classes 
that divide employees into pensionable or not-pensionable — second discrimina- 
tor) . How are these principles relevant to class hierarchies ? This still is an open 
and somewhat controversial question. 



7.2 Links between Classes and Instances 

Traditional object-oriented programming languages assume that instances are 
created with respect to a class, and remain linked to this class all their life-time. 
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The rule also is that an instance belongs to a single class (mono-instanciation), 
even if less common models with multi-instanciation exist izia. 

By contrast, in object-oriented representation systems and databases, having 
instances more independent of classes is an important need |w4l Iw8l [4). This 
characteristic extends to prospective models like |w3l lw mm or that allows 
objects to change their classes depending on property-based classification that 
augments the explicit type-based classification of ordinary classes. 

8 Techniques and Strategies 

Inductive vs. Deductive Classification. Classification can be used in as- 
cendant (inductive) and descendant (deductive) ways. In the work of |w9j . for 
example, interclassing is a form of inductive classification. When a class is de- 
rived to obtain a new class (subclass), as in the usual programming practice, the 
classification is rather descendant. 

Inductive discovery of a class hierarchy is usually called conceptual clustering 
|20l Iw21 Iw6l Iwl3| in the machine learning field while the term classification (or 
hierarchical classification) is used to refer to the deductive process of finding 
the best place for a new instance within a fixed class hierarchy jSj [T^ Iw8l Iw4| . 
Concept formation is used to characterize the fact that the class hierarchy is 
discovered incrementally 1121 . Conceptual clustering and concept formation fall 
under the category of unsupervised learning because the classes are not known 
in advance. 

Couceptual Clustering iu Question. In [wl3j . a comparison has been car- 
ried on the relations existing between similarity-based classification and Ga- 
lois lattice-based classification (also known as formal concept analysis pTT]l: 
similarity-based classification is flexible and easy, while Galois lattice-based clas- 
sification is a more complete classification method. There are a number of situ- 
ations where similarity-based classification can complement Galois lattice-based 
classification and conversely. This contribution opens a promising research way, 
as such clustering approaches are more and more used for software class hierar- 
chies construction iniEniiiiissiiiB]. 

The complexity of the classification operation was hightlighted in [w2l IwBj : 
classification is a NP-hard problem in the general case and this must be taken 
into account for realistic and large problems involving classification m- A kind 
of anytime classification may be studied for real time problems, as shown in 
|w2| . In the case of graph-based description languages, | w6| proposes to use 
rather models for which the complexity of generalization is polynomial, as for 
example rooted labeled locally injective graphs. 

9 Conclusion 

Many topics have been addressed and discussed during the workshop. Glassifica- 
tion is very ubiquitous and appears to be a central tool both for object-oriented 
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representation and object-oriented programming. The workshop has provided a 
number of criteria to compare and appreciate classification techniques or results, 
the main references on that issue are |w71 Iw m- 

Many directions have still to be studied and developed. Classifiers as used in 
object-oriented representation systems could be used with profit for class design 
in object-oriented programming, i.e. building and reorganizing class hierarchies. 
As well, aspects of object-oriented programming such as the design and the 
management of code artifacts, persistence, could be considered also with profit 
in the field of object-oriented representation systems. 

A main issue is ensuring the consistency between the different classification 
operations made at different steps in the life-cycle of a software (discovery and 
organization of classes in design, classes in programming, dynamic aspects, pat- 
terns, etc.). In object-oriented programming, for example, an instance is created 
from a class, but nothing ensures that it is the best fitting class for that instance. 
Classes can be organized into single inheritance hierarchies at the design step, 
and into multiple inheritance hierarchies in the code (or the opposite): which 
tools may guarantee a systematic transition between the two models? 

Software classification opens a very promising way that could be extended 
and applied to modeling artefacts, such as UML diagrams, maybe with other 
forms of description languages. 

We think that “classification”, in all its meanings, is something that struc- 
tures very well the view one can have on the object-oriented field. 

Acknowledgments. The authors would like to thank Tom Mens who con- 
tributed by fruitful notes to this document. 
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11 Position Papers 

All position papers can be seen on the web site of the workshop: 
http : / / WWW . lirmm.fr / ~ huchard/ WorkshopClassif . html 

They are also available in: 

Contributions of the ECOOP’OO Workshop, ’’Objects and Classification, A natu- 
ral convergence”. Research Report LIRMM n. 00095, Marianne Huchard, Robert 
Codin, Amedeo Napoli, (Eds) 

[wl] D. Bardou. ’’Inheritance Hierarchy Automatic (Re) organization and Prototype- 
based languages” 

[w2] I. Bournaud. ’’Automatic objects organization” 
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[w3] A. Capouillez, R. Chignoli, P. Crescenzo, P. Lahire. ’’Towards a More Suitable 
Class Hierarchy for Persistent Object Management” 

[w4] C. Capponi, J. Gensel. ’’Classifications among classes and associations: the 
A ROM’s approach” 

[w5] K. De Hondt, P. Steyaert. ’’Exploiting classification for software evolution” 

[w6] M. Liquiere. ”A machine learning model for generalization problem in object- 
oriented approaches” 

[w7] K. Mens, T. Mens. ’’Codifying High-Level software Abstractions as virtual classi- 
fications” 

[w8] A. Napoli. ’’Classification and Disjunction in object-based representation systems” 
[w9] P. Rapicault. ”A pragmatic approach to hierarchy evolution” 

[wlO] D. Rayside, G.T. Campbell. ”An Aristotelian Introduction to Classification” 
[wll] D. Tamzalit, M. Oussalah. ” A model for Object Structures Emergence” 

[wl2] T. Tourwe, K. De Voider. ’’Using software classifications to drive code genera- 
tion” 

[wl3] P. Valtchev, R. Missaoui. ’’Similarity-based Clustering versus Galois lattice build- 
ing: Strengths and Weaknesses” 

[wl4] B. Wouters, D. Deridder, E. Van Paesschen. ’’The use of Ontologies as a backbone 
for use case management” 
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Abstract. Architecture represents the most fundamental set of design 
decisions about a system, and evolution aspects have to be considered 
at this level. Also, assuming that a deliberate “architecting” step has 
been taken, architecture is the stage where the input from requirements 
is most evident and can be inspected from an evolvability point of view. 
Moreover, the ever-changing world makes evolvability a strong quality 
requirement for a software architecture. More generally, software evo- 
lution and its management have been attracting considerable interest 
in recent years in component-based systems, as well in object-oriented 
legacy systems that need to be transformed into full-fledged frameworks. 
The first workshop on object-oriented architecture focussed on how to 
capture and assess architectural quality of object-oriented software. The 
second workshop was organized around three main aspects to support 
evolution: concepts; methods; techniques; and evaluation. This third edi- 
tion addresses more specific topics that resulted from the previous edi- 
tions: descriptions of types of architectural evolution, levels of repre- 
sentation to detect architecture changes, and the role of domain and 
requirements analysis in software and systems architecting. 



1 Introduction 

The workshop aimed at distilling the views of participants from industry and 
academia on the issue that should become part of any future research agenda 
into the evolution of object-oriented system and software architectures. 

One day was allocated for the workshop (Tuesday June 13th 2000), and a 
total of 10 position papers were accepted. All were deemed of a good quality and 
scope. A total of 16 people participated in the workshop. 

In preparation for the workshop, the participants were requested to scan the 
papers presented in the workshop and read the report of the previous workshops 
in the series: 

- EGOOP’2000, 

http:/ /www. emn.fr/borne/EGOOP2000/ W17-ListOfPapers.html 



J. Malenfant, S. Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 138- 11491 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 
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— ECOOP’1999 workshop reader, A.Moreira and S.Demeyer (eds), Springer, 
LNCS 1743, pages 57-79. 

— ECOOP’1998 workshop reader, S.Demeyer and J. Bosch (eds). Springer, 
LNCS 1543, pages 44-71. 

The organisers decided to select three papers for presentation to the whole 
workshop; the selection criteria being a representative variety of the orientations 
of the papers accepted, in a way that offered different perspectives on object- 
oriented architectural evolution, and the potential for generating issues that can 
stimulate the discussions. 

The first part of the workshop (from 9-10:30) was used in opening and intro- 
ducing the workshop to the participants. The following sessions were allocated 
to group discussions, followed by a plenary session from 16:00 to 17:30. 

We also asked that presentations should show the presenter’s approach and 
particular points of view of software architectural evolution, and strongly sug- 
gested that every presentation was ended with some points of discussions and 
issues. Below are the papers selected and the reasons for selecting them: 

— 00 Frameworks as Components - Experiences of Framework Evolution 
(Michael Mattsson - University of Karlskrona/Ronnehy, Sweden). 

The organisers thought that this paper contained a really good experience 
report on a possible classification of evolution categories. This presentation 
raised the following issues : 

• Can the result form a basis for design guidelines for alleviating future 
framework component evolution? 

• How much attention should be paid to an architecture’s component evo- 
lution compared to architecture evolution? 

• Which are the major problem/hindrances for evolving a product line ar- 
chitecture? A product architecture based on a product line architecture? 

— Evolution by Contract (Jose Luiz Eiadeiro - King’s College London, United 
Kingdom, Luis Filipe Andrade - Oblog Software, Portugal). 

This paper was about a conceptual object-oriented contract-based design 
scheme to support the architectural evolution of software. It was regarded 
by the organisers to be clear, very well- written and addressed a number of 
points vital to the software architecture community. It is also supported by 
a clear and very well-chosen example. 

— Finding Refactorings via Change Metrics (Serge Demeyer - University of 
Antwerp, Belgium). 

The organisers felt that Serge’s experiences on reverse engineering projects 
would provide a wide interest for the discussion. This presentation raised the 
following issues : 

• What is the difference between architecture and design? 

• Is design drift really bad? May be it is the original design that is wrong? 

• What are the symptoms for design changes? 

• Can we use changes for reverse engineering? 
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2 A Comparative Summary of the Contributions 

The papers received covered a number of topics relating to object-oriented ar- 
chitectural evolution, covering the range from the philosophical and speculative 
(eg the paper by Galal) to the pragmatic that offers particular techniques for 
directing software refactoring, using metrics, to support architectural evolution. 

The full contributions and their abstracts are available at 
http://www. emn.fr/borne/ECOOP2000- W1 7.html 
The 10 papers are the following: 

~ An Architectural Playground (Xavier Alvarez, Isabelle Borne, Ecole des Mines 
de Nantes, France) 

— A Formal Language for Describing Evolving Software Systems: Architectural 
Compositionality and Evolvability ( C.Chaudet, M. Greenwood, F. Oquendo, 
and B.Warboys, University of Savoie, France) 

— Finding Refactorings via Change Metrics (Serge Demeyer, University of 
Antwerp, Belgium, Stephane Ducasse and Oscar Nierstrasz, University of 
Bern, Switzerland) 

— Supporting Evolution Recovery: A Query-based Approach (Stephane Ducasse, 
Michele Lanza, and Lukas Steiger, University of Bern, Switzerland) 

— Evolution by Contract (Jose Luiz Fiadeiro, King’s Gollege London, United 
Kingdom, and Luis Filipe Andrade, Oblog Software SA, Portugal) 

— Software Architectonics: Towards a Research Agenda (Galal H. Galal, Mid- 
dlesex University, United Kingdom) 

— Architectural evolution of product families (Alessandro Maccari, Nokia Re- 
search Genter, Finland) 

— 00 Frameworks as Components - Experiences of Framework Evolution 
(Michael Mattsson, University of Karlskrona/Ronneby, Sweden) 

— On the Use of Declarative Meta Programming for Managing Architectural 
Software Evolution (Tom Mens, Kim Mens, and Roel Wuyts, Vrije Univer- 
siteit Brussel, Belgium) 

— Test-first approach for evolvable architectures (Ghristian Wege, Daimler- 
Ghrysler AG, Germany) 

The papers by Galal; Maccari; Xavier & Borne; and Wege tended towards 
the philosophical, mainly arguing for novel thinking and perspectives in thinking 
about sofware architecture, and how its evolution might be studied, managed or 
effected. For example, analogies with buildings and urban layouts were offered. 
In the middle of the range, were papers that described experiences in studying 
and managing software evolution, such as the papers by Mattsson and Fiadeiro 
& Andrade. The remaining papers argued for the role of specific techniques in 
supporting architectural evolution, such as Declarative Programming (Mens et 
ah); Using a Query-based Approach (Ducasse et ah); and a formal language for 
describing evolving software systems (Ghaudet et ah). 

A clear link could be discerned between the papers by Galal, who sketches 
the way in which software could be thought of as buildings or urban spaces. 
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Maccari, who refers to Galal’s notion of software architectonic and describes an 
analogy between the change of buildings and change in software. A further link 
was observed between the paper Fiadeiro & Andrade, who offers a very concrete 
and well-illustrated example and position papers in the earlier instances of this 
workshop on the virtues of layered architectures. 



3 A Summary of the Debates 

The organisers suggested two ‘focus’ questions that relate to the issues raised in 
the position papers, these were: 

1. From some kind of the domain model, can we predict certain types of archi- 
tectural evolution that we are interested in? 

2. What levels of representation granularity are most useful in tracking or de- 
tecting architectural evolution? 

When these two questions were proposed to the participants two more focus 
questions were proposed: 

— What kinds of architectural evolution do we have? (run-time evolution/ 
design-time evolution) 

— Can we match tools and environment to types of evolution, especially archi- 
tectural drift? 

A discussion ensued, after which it was decided to merge the last three ques- 
tions together. In this way, the participants divided into two groups, each dis- 
cussing one of the two focus questions in detail. 

Participants selected tracks to join, and every group was asked to select a 
discussion chair and a reporter. The members of the organising committee joined 
the two tracks. After having worked on answering these questions in smaller 
groups, the workshop came together in a final plenary session where all the results 
of the different track discussions were presented and discussed. The members of 
the organising committee wrote the following reports on the respective tracks. 

3.1 From Domains Can We Reason about Types of Evolution and 
Software System Evolution? 

Participants: Roel Wuyts, Michael Mattsson, Xavier Alvarez, Serge Demeyer, 
Christian Wege, Jose Fiadeiro, and Calal H Calal. 

As a result of the discussion, moderation by a chairman, the group put for- 
ward the following positions: 



Architecture versus Structure. It was felt that it was useful to think of 
software structure (meaning its individual components, such as modules and how 
they relate to each other) as being distinct from its architecture, referring to the 
strategy of arranging groups or clusters of components together. Architecture is 




142 



Isabelle Borne et al. 



thus much more coarse-grained than mere structure. On this basis of reasoning, 
architectural evolution is distinct from structural evolution. It is desirable to 
minimise architectural evolution: architecture (in its coarse-grain sense) should 
be as stable as possible. The need to change the architecture, or evolve it, should 
be minimal. 

Architecture in effect puts limits on, or constrains, the structural evolution of 
software. By the same token, architecture enables or facilitates certain structural 
evolution changes. 

It is desirable to reduce the amount of change to architecture. For example, if 
we have a sound architecture for a system A, which provides a web interface (e.g. 
Servlets, Java Server Pages), and then a new requirement comes up to support 
WAP (Wireless Application Protocol). A good architecture could be to provide 
the raw data in some intermediate format (e.g. XML) and attach several view 
processors on top of that (for HTML and WML) . It is likely that some changes to 
the application architecture will be necessary to cope with the new requirements 
imposed by the various dimensions of the WAP compatibility requirement. But 
the change in architecture would be quite dramatic if we had not thought about 
that in the first version of the system. The idea here is that some change of the 
architecture is induced by the change in technology used. For a robust application 
architecture, it should be possible to accommodate the new requirement without 
having to affect such dramatic changes to its architecture so as to completely 
re-architect it. The latter case would not be mere architectural evolution, since 
significant changes have had to be made to the original architecture, but rather a 
complete change. It should not be necessary to completely change an architecture 
to extend or change the functionality of the software that it supports. This is 
regardless of the relative ease or cost of effecting such a dramatic change. This 
means that the concept of architectural robustness should refer to the ease with 
which an existing architecture accommodates changes of functionality, platform 
etc. 

What Might Software Architecture Be? Categories of components or el- 
ements that share the frequency (or likelihood) of change. Put another way, 
software architecture is composed of categories, each category contains software 
components that exhibit shared stability characteristics. This view is based on an 
analogy from the discipline of architecture and was elaborated on in a paper for 
the first workshop in the series (see http://www.emn.fr/borne/). Architecture is 
more than merely showing how software components interconnect. 

Types of Evolution. Architectural shift/tilt, meaning relatively minor or local 
changes to the architecture without propagating the effect of the change to the 
rest of the architecture is acceptable when needed. This position is premised on 
the notion of architecture presented above, as consisting of categories. We can 
discern the following types of architectural evolution: 

— a) Intra-category (structural) evolution. This is when components within one 
category (or layer) are changed. 
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— b) Inter-category evolution (migration to re-organise). This is when some 
components are moved from one category to another, to improve or evolve 
the architecture, for example, to make it more robust in the face of a new 
requirements profile. 

— c) Category evolution (such as performing merge, remove, split, append ope- 
rations on categories of components). This is when the fundamental categori- 
sation of components in an architecture is changed. This is the more dramatic 
and costly type of evolution, which must be done with care to reduce the 
likelihood of introducing defects. 

Categories can be layered, stacked or put in a grid of some sort. The point 
here is that the categorisation is the fundamental expression of architecture, 
which must be the subject of architectural reasoning and evaluation. 



Using the Domain. The group converged on the view that the original problem 
domain has a major role to play in deriving software architectures, as well as 
reasoning about them. At this stage of the development of the discipline of 
software architecture, it is possible to research the domain (which the software 
aims to model or to serve in some way) in at least two directions: forward and 
in reverse. What the group suggests below effectively outlines a new research 
agenda into software architectural change. 

Forward (from Domains to Architectures): this aims at studying the original 
problem domain to better derive software architecture. The following steps are 
suggested: 

1. Study the domain very carefully to establish and understand its categories 
of change. An issue here is how to exactly perform modelling, meaning what 
methodological approach to follow and what modelling primitives to employ. 

2. It must be recognised that the understanding established in (1) above is 
approximate and contingent, and there are alternative futures of how ca- 
tegories might change. There are competing visions of what categories of 
change are present in a particular problem domain, and these are grounded 
in the assumptions made about the range of possible futures for the problem 
domain. 

3. Build an explicit model of how the architecture maps to the results of (2). 
However, there should be a range of models to represent a range of possible 
future scenarios. As such, there may more than one candidate architecture, 
and the range of scenarios decided or elicited helps in choosing between them. 

Reverse (from extant systems to detect the state of their architectures) in 
the following ways: 

1 . Study the legacy systems to extract the final state of their architectures after 
evolution (issue: what levels of abstraction should be used in modelling?). 

2. Study which representation level of architecture corresponds more closely to 
how the domain changed, or in other words, its dynamics. 
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References. Some of the discussions in this group relate to G H Galal’s writing 
on the nature of software architecture, and the role of domain and requirements 
analysis in software and systems architecting. References to these can be found 
at http://www.cs.mdx.ac.uk/staffpages/Galal/ 

3.2 What Levels of Representation (Granularity) Are Useful in 
Tracking/Detecting Architectural Evolution? 

Participants: Luis Andrade, Huw Evans, Kin Mens, Tom Mens, Ghristelle Ghau- 
det, Alessandro Maccari, Gabriela Arevalo, Stephane Ducasse, Isabelle Borne. 

Architecture Views. The question of whether a single architectural descrip- 
tion can represent a complete system is still an open question. Moreover, changes 
are triggered by evolution within the application domain, and by the evolution 
of the technology itself. The group agreed that one architecture view is not suffi- 
cient to explore certain aspects of evolution and proposed to distinguish technical 
views and domain specific views for an architecture. 

Layered Architecture. The group also decided to consider a layered approach 
to study the question. Gommon layered systems are organised hierarchically 
and every layer is made of components and connectors, defining how the layers 
will interact. Models should reflect and made explicit, both at the requirements 
engineering and design stages, the very entities over which change applies and 
how the different components of the system interact. By making components 
and connectors explicit, we can address change in a more direct and manageable 
way. 

A Pyramid Representation. The discussion brought out that the levels of 
representation useful to manage architectural evolution and locate changes are 
at least a combination of layered views: a horizontal cutting of layers (kernel, 
domain, user interface) and a vertical cutting of technical and domain specific 
views. The number of layers depending on a view is variable, leading to a pyramid 
representation. Other aspects to take into account in the representation are the 
constraints and relationships that can appear between views and between layers. 
Finally the group addressed the need of mechanisms to build queries on change 
impact analysis (query mechanism, reasoning mechanism). 

The problem is complex and we are still far from the solution but we tried 
to bring out promising ideas and we think that the solution is domain specific. 

4 Conclusion 

The workshop participants felt that they were embarking on a new direction for 
research into software architecture, that is effectively at odds with the main- 
stream software engineering view of what software architectural evolution is or 
how it might be researched. 
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One of the major themes that emerged from this workshop, that which at- 
tempts to relate the understanding and analysis of the problem domain dynamics 
to software architecting decisions, is seriously under-represented in the literature. 
The workshop participants agreed that analysing the domain had a major role 
to play in deriving software architectures. There has not been sufficient research 
in this area, a situation that we hope will change. 

The participants felt that more work needs to be carried out on the views 
reached in this workshop. It was suggested that the participants needed to keep 
in contact with each other to collaborate on joint research projects to illuminate 
the issues that came to surface in this workshop. 

5 Related Work 

This section contains a guide to the literature, links to relevant web sites. Before 
giving these, we mention an article, written by one of the workshop organisers, 
focusing on a major theme that has emerged from the workshop, and that relates 
requirements analysis and architectural issues: 

Galal, G. H. (1999). On the Architectonics of Requirements. Requirements 
Engineering Journal 4(3): 165-167. (full text is available in the research publica- 
tions section of the web site: http://www.cs.mdx.ac.uk/stafFpages/Galal/) 

The past two instances of this workshop also articulate elements of this issue 
and related vision for a research agenda. Papers can be found at: 
http:/ /www. emn.fr/borne/EGOOP98-W02.html 
http:/ /www. emn.fr/borne/EGOOP99-OOAE.html 



5.1 Guide to Literature 

Garlan and Shaw define software architectures to be a level of design that is 
at a much higher level of abstraction than just algorithms and data structures. 
The overall system structure must be considered a new problem and gross orga- 
nizational issues and global control structures become considerations, together 
with communication protocols and methods of data access and data synchro- 
nization. In addition, composition of design elements, scaling and performance, 
and selection among design alternatives must also be considered. 

The Second Workshop on Object-Oriented Architectural Evolution focused 
on the evolution of such systems. Architectural evolution is any kind of change 
or extension to the architecture of a system for whatever reason, e.g., perfective 
maintenance or the introduction of new functionality. Ghanging the architecture 
of a system may involve changing its paper-based design or its software, or both. 

Most of the software architecture literature can be found in a number of books 
and in the proceedings of a handful of workshops and conferences. The most 
widely referenced book is Software Architecture: Perspectives on an Emerging 
Discipline^ David Garlan and Mary Shaw, Prentice Hall (pub.), ISBN 0131829572. 
Others software architecture books include: Software Architecture in Practice, 
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Len Bass, Paul Clements, Rick Kazman and Ken Bass, Addison- Wesley (pub.), 
ISBN: 0201199300; and Applied Software Architecture The Addison-Wesley Ob- 
ject Technology Series, Christine Hofmeister, Robert Nord, Dilip Soni, Addison- 
Wesley (pub.), ISBN: 0201325713. 

The discipline of software architecture cannot be considered in isolation. The 
related areas of component-oriented software and design patterns should also be 
considered and all three, or any two, can be used in combination. 

These related disciplines are well described in Component Software : Be- 
yond Object-Oriented Programming, Clemens Szyperski, Addison-Wesley (pub.), 
ISBN: 0201178885 and Design Patterns, Erich Gamma, Richard Helm, Ralph 
Johnson, John Vlissides, Addison-Wesley (pub.), ISBN: 0201633612. We can 
see a coming together of software architectures and design patterns in books 
such as Pattern Oriented Software Architecture : A System of Patterns, Frank 
Buschmann, Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, 
John Wiley (pub.), ISBN: 0471958697. 

The International Software Architecture Workshops (e.g., ISAW-2, ISAW-3 
and ISAW-4, see below on searching google . com) are the main workshops for 
the study of software architecture and are run in conjunction with the Inter- 
national Conference on Software Evolution (ICSE). Other workshops are more 
specialised, e.g., the International Workshop on the Development and Evolution 
of Software Architectures for Product Families; the Nordic Workshops on Soft- 
ware Architecture and the Workshop on Compositional Software Architectures. 
See below for references to these. 

Many papers have been written on the topic of software architectures and 
it is an active area of study. Therefore, we give here a number of URLs to 
bibliographies and other starting points for the interested reader. 



Bibliography and Related Web Sites 

— ICSE Bibliography from 1991 to 1997 

http:/ /pele.ilab.sztaki.hu/~ ahajnal/publications/icse.htm 

— Bredemeyer Consulting’s Software Architecture papers and download page 
http://www.bredemeyer.com/bibliogr.htm 

— Software Architecture: An Annotated Bibliography, Waterloo University, 
Canada 

http:/ /pig. uwaterloo.ca/~ holt/cs/746/98/biblio.html 

— Bibliography on Software Architecture Analysis, FIT, Japan 
http://www.fit.ac.jp/~ zhao/pub/sa.html 

— Software architecture resources at SRC, Netherlands 
http://www.serc.nl/people/florijn/interests/arch.html 

— Nova Southeastern University, Object-Oriented Software Architectures Page 
http://www.scis. nova.edu/~ fangchih/ 

— H. James Hoover’s Object-Oriented Software Architecture Page 

http : / / WWW .cs . ualbert a. ca/ ~ hoover / cmput40 1 / Software Arch / section / 
biblio.htm 




Object-Oriented Architectural Evolution 



147 



— The Darpa STARS Software Architecture Papers 

http: / / www.asset.com/ stars/darpa/Papers/ ArchPapers.html 
~ Jim Holt’s Software Architecture Page 
http://powerlips.ece. utexas.edu/~ jolt/ 

— Amnon H. Eden Research Pages 
http://www.cs.concordia.ca/~ faculty/eden/architecture.html 

— General Information on Objects and Components/ Architecture and Design 
http://www.everest.nl/cetus/oo_design.html 

— ChiMu Corporation’s Reading and References Page 
http://www.chimu.eom/publications/javaStandards/part0005.html 



5.2 Relevant Web Sites 

Here is a very selective list of web sites that deal with software architectures, 
maintenance and evolution in one form or another. Unfortunately, space pre- 
cludes this from being exhaustive, so for more information, try searching 
WWW. google . com with an appropriate search term, e.g., software architecture 
research; or proceedings software architecture; or perhaps one of the 
International Software Architecture Workshops, e.g., ISAW-4 or try software 
architecture bibliography. 

— David Garlan’s Web Page on Software Architectures: 
http://www.es. emu. edu/~ garlan/ 

— Software Architecture Resource Sites at UMass 

http: / / www2.umassd.edu/SECenter / SAResources.html 

— UCI’s Software Architecture and Evolution Work 
http://www.ics.uci.edu/pub/c2/ 
http://www.ics.uci.edu/pub/edcs/ 

— Model Problems in Software Architecture from CMU 
http : / / WWW .cs . emu .edu/People /ModProb / 

— Software Architecture Papers from the SERL Group at the University 
of Colorado: http://www.cs.colorado.edu/serl/arch/Papers.html 

— The First Working IFIP Conference on Software Architecture 
http://www.ece. utexas.edu/~ perry/prof/wicsal/cfp.html 

— Nordic Workshop on Software Architecture 
http:/ /www. ipd.hk-r.se/RISE/NOSA99/ 

— Workshop on Compositional Software Architectures 
http://www.objs.com/workshops/ws9801/report.html 

— Report on the Second International Workshop on the Development and 
Evolution of Software Architectures for Product Families 

http:/ /www.sei.cmu.edu/publications/featured/technical.html:/^98-sr-003 
~ The FAMOOS Project: http://dis.sema.es/projects/FAMOOS/ 

— DARPA Evolution Work: http://www.darpa.mil/ito/research/edcs/ 

— Software Evolution Group at UCSD 
http://www-cse.ucsd.edu/users/wgg/swevolution.html 

— The Centre for Software Maintenance: http://www.dur.ac.uk/CSM/ 
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— Automated Software Engineering Journal 
http:/ /www. wkap.nl/journalhome.htm/0928-8910 

— Active Composition Group at UC Davis 
http://arthur.cs. ucdavis.edu/~ pandey/Research/act. comp.htm 

— Feast Project papers on Software Evolution 
http://www-dse.doc.ic.ac.Uk/~ mml/feast/papers.html 

— Distributed System Technology Centre at Queensland University of Tech- 
nology: http://www.dstc.qut.edu.au/ 

— Programming Language Research at CMU 
http://www.cs.cmu.edu/afs/cs.cmu.edu/user/mleone/web/ 
language-research.html 

— ASTER Software Architectures for Distributed Systems 
http://www-rocq.inria.fr/solidor/work/aster.html 

— Bauhaus: Software Architecture, Software Reengineering, and Program Un- 
derstanding 

http://www.informatik.uni-stuttgart.de/ifi/ps/bauhaus/index-english.html 

— Idioms and Patterns as Architectural Literature, James O. Coplien 
http: / / wwwl.bell-labs.com/ user / cope /Patterns / 
IeeeSoftwareSpecialPatternIssue.html 

6 Workshop Participant’s Email Addresses and Webpages 

1. Xavier Alvarez, Ecole des Mines de Nantes, France (Xavier.Alvarez@emn.fr) 

2. Gabriela Arevalo, Ecole des Mines de Nantes, France (garevalo@emn.fr) 

3. Luis Andrade, Oblog Software S.A, Portugal, (landrade@oblog.pt, 
http: / / www.oblog.pt) 

4. Isabelle Borne, Ecole des Mines de Nantes, France (Isabelle.Borne@emn.fr, 
http://www.emn.fr/borne/), 

5. Christelle Chaudet, Univesity of Savoie at Annecy, France 
(christelle.chaudet@esia.univ-savoie.fr) 

6. Serge Demeyer, University of Antwerp, Belgium 
(Serge.Demeyer@uia.ua.ac.be, http://win-www.uia. ac.be/u/sdemey/) 

7. Stephane Ducasse, University of Bern, Switzerland (ducasse@iam.unibe.ch, 
http://www.iam.unibe.ch/~ ducasse/) 

8. Huw Evans, University of Glasgow, United Kingdom (huw@dcs.gla.ac.uk, 
http://www.dcs.gla.ac.Uk/~ huw) 

9. Jose Luiz Fiadeiro, King’s Gollege London, United Kingdom 
(jose@fiadeiro.org) 

10. Galal Hassan Galal, Middlesex University, United Kingdom (Galal@acm.org, 
http : / / www.es . mdx.ac.uk / st affpages /galal/ ) 

11. Alessandro Maccari, Nokia Research Genter, Finland 
(alessandro.maccari@nokia.com) 

12. Michael Mattsson, University of Karlskrona/Ronneby, Sweden 
(Michael.Mattsson@ipd.hk-r.se, http:/ /www.ipd.hk-r.se/~ michaelm) 

13. Kim Mens, Vrije Universiteit Brussel, Belgium (kimmens@vub.ac.be, 
http: / /progwww. vub.ac.be/~ kimmens) 
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14. Tom Mens, Vrije Universiteit Brussel, Belgium (tommens@vub.ac.be, 
http : / /progwww . vub . ac .be/ ~ tommens) 

15. Christian Wege, DaimlerChrysler AG, Germany (christian.wege@dcx.com, 
http: / /www. purl.org/net /wege) 

16. Roel Wuyts, Vrije Universiteit Brussel, Belgium (rwuyts@vub.ac.be, 
http://prog.vub.ac.be/~ rwuyts) 
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Abstract. This workshop objective is to identify the main lacks of UML 
for developing real-time embedded systems and the main prospective di- 
rections for research to these difficulties. For that, it aims to gather aca- 
demics and industrial people to discuss on industrial needs, on formalisms 
prospects and on advanced solutions. It tries to tackle the three main part 
of a development cycle: specification/analysis, design/implementation 
and validation. Three main sessions have emerged from the workshop 
submissions. The first one was focused on setting the end users require- 
ments for UML modeling of real-time embedded systems. The second 
has been focused on design and implementation techniques proposals 
and experiences. The third has been centered on formal techniques for 
the validation of the applications from their UML model. 
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Workshop Topics 

The adoption of object-oriented modeling in the real-time domain appears to be 
essential in order to face rapidly changing market conditions. The main obsta- 
cles are a lack of standards and inadequate adaptation to real-time needs. With 
the standardization of UMLl.l and now UML1.3, the first main drawback is 
being overcome. The challenge is then to handle these notations properly within 
an object-oriented methodology and framework well suited to embedded real- 
time. This workshop aims to gather academics and industrial people to discuss 
the use of UML for the development of embedded real-time systems. It tries 
to tackle the three main part of a development cycle: specification/analysis, de- 
sign/implementation and validation. Thus, it addresses the following topics: How 
to capture and specify time constraints (Priority, Periodicity, Deadline, ...)? How 
to adapt analysis models for real- time systems? How to design solutions which 
effectively take care of the real-time aspects (e.g. concurrency, deadlines, hard- 
ware interfaces, synchronization, etc.)? How to link UML models to real-time 
object-oriented languages? What are the features of the generated code (size, 
quality, portability, ...)? How to support automatic (or semi-automatic) code 
generation from design models, techniques of models transformation, patterns 
and frameworks specific to real-time systems? How to validate the dynamic be- 
havior and the fulfillment of the time constraints? How to insure consistency 
of system described through different types of models (structural, interaction, 
behavior, ...)? 

Workshop Participants 

Joelle AUBRY, PSA, France, OtondoJ@netcourrier.com 
Jean-Philippe BABAU, INSA-Lyon, LSI, France, jpbabau@if.insa-lyon.fr 
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Germany, beckert@ira.uka.de 

Udo BROCKMEYER, OFFIS e.V., Germany, udo.brockmeyer@offis.de 
Werner DAMM, OFFIS e.V., Germany, Werner.Damm@OFFIS.de 
Alexandre DAVID, Uppsala University, Department of Computer Systems, 
Sweden, adavid@DoCS.UU.SE 

Pierre-Yves DUVAL, CPPM (Centre de Physique des Particules de Marseille), 
France, duval@cppm.in2p3.fr 

Sebastien GERARD, LETI (CEA - Technologies Avancees), France, 
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Nikos S. VOROS, INTRACOM S.A., Geeee, voni@INTRACOM.gr 
Florian WOHLGEMUTH, DaimlerChrysler, Germany, 
fforian.wohlgemuth@daimlerehrysler;eom 



1 Introduction 

During the last years UML has beeome the lingua franea among system mod- 
elers all over the world. Although its presenee in the software domain has been 
sueeessful, UML still laeks signifieant semanties that will allow its dominanee 
in speeifie domains, like the one of real-time systems; the deseription of the 
real-time behavior of sueh systems is not completely satisfying yet. Available 
methods provide good support for modeling the parallelism in an application, 
but are often poor to express quantitative real-time features such as deadlines, 
periods, priorities etc. In the next sections we present the different aspects of 
the real-time problem: what companies developing real-time applications wish 
to do, and which of their needs the tool vendors can could fulfill. Of course, what 
is the future of UML in the real-time domain and how it could be extended in 
order to allow the efficient development of complex real-time systems was also 
discussed during SIVOOES workshop. 

Among the participants of the SIVOOES workshop hosted at ECOOP 2000, 
were and the companies/institutes participating in the AIT-WOODDES project 
(http/ / :wooddes. intranet.gr). AIT-WOODDES project focuses on the high level 
specification of embedded real-time systems allowing evolving design of product 
applications so as to quickly and easily adapt the product to the market evo- 
lution and to master increasing complexity of such products. The project will 
deliver an environment for the design of embedded systems using, where pos- 
sible, existing standards, techniques and products. This environment will offer 
system description and development tools providing a homogeneous and contin- 
uous support for the development process of embedded systems. The project is 
tackling this problem by using the UML (Unified Modeling Language) notations, 
to completely describe embedded and real time characteristics of such systems 
and also to benefit from the advantages of a component based approach. The 
results of the project are expected to have major impacts on: 

— development time and cost 

— quality of delivered products 

— continuity of the development process 
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To be competitive, companies need to decrease time to market. To achieve 
this, the project proposes to optimize the use of different actors know-how in 
design and development techniques: 

— to investigate and adapt the UML notations towards a development process 
for embedded systems with Real-time constraints. 

— to implement homogeneous modeling tools for data exchange between people 
from different areas using different data administration systems ; 

— to extend validation tools to be used early in the process (during the proto- 
typing phase) and to cover both component validation and integration. 



2 Overview of the AIT-WOODDES Project 

The AIT-WOODDES project motivating the workshop proposal has been rapidly 
presented to introduced the workshop sessions. The presentation has been per- 
formed by A. Gilberg from PSA (Peugeot Citroen Automobiles). AIT- 
WOODDES is a 1ST Program project (IST-I999-I0069) of the 5th PCRD. It 
belongs to Action IV. 3.1: Component based System Engineering. It has started 
at the beginning of year 2000 for 3 years. Consortium is constituted as following: 

— End users 

• PSA, France: car builder (Prime of the project) 

• Mecel (Delphi), Sweeden: car equipment supplier 

• INTRACOM, Greece: telecom service and system developer 

— Laboratories 

• CEA-LETI, France: technology provider for real-time development with 
UML (ACCORD framework) and for automatic test case generation 
(AGATHA tool) 

• University of Uppsala, Sweeden: technology provider for model checking 
of timed automata (Uppal tool) 

• OFFIS, Germany: technology provider for formal model checking (Model 
Checker tool) 

— Tool vendors 

• I-logix, Israel: editor and vendor of a UML-RT development tool (Rhap- 
sody) 

• Telelogic, France: editor and vendor of a UML/SDL development tool 
(ObjectCEODE) 

The AIT-WOODDES project will focus on the high level specification of em- 
bedded real time systems allowing evolving design of product applications so as 
to quickly and easily adapt the product to the market evolution and to master 
increasing complexity of such products. The project will deliver an environment 
for the design of embedded systems using, where possible, existing standards, 
techniques and products. This environment will offer system description and 
development tools providing a homogeneous and continuous support for the de- 
velopment process of embedded systems. The project is tackling this problem by 
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using the UML (Unified Modelling Language) notations, to completely describe 
embedded and real time characteristics of such systems and also to benefit from 
the advantages of a component based approach. The results of the project are 
expected to have major impacts on: 

— development time and cost 

— quality of delivered products 

— continuity of the development process 

To be competitive, companies need to decrease time to market. To achieve 
this, the project proposes to optimise the use of different actors know-how in 
design and development techniques: 

— to investigate and adapt the UML notations towards a development process 
for embedded systems with Real Time constraints. 

— to implement homogeneous modeling tools for data exchange between people 
from different areas using different data administration systems ; 

— to extend validation tools to be used early in the process (during the proto- 
typing phase) and to cover both component validation and integration. 

Benefits for end-users will be a new object-oriented development process that 
considerably reduces the costs via: 

— decreased design, prototyping and validation time since the users can easily 
derive from the UML high-level model many different specific models; 

— decreased time of model variants implementation for the suppliers; 

— decreased feasibility and analysis time; 

— increased product quality through better reliability and safety, earlier vali- 
dation of the specifications and reuse of successful components. 

Benefits for tool providers will be an integrated design toolset that takes as 
input UML models, validates the system design and automatically generates the 
executable model (i.e. the target code). The approach developed in the project 
should result in a proposal for UML that solves many deficiencies of the current 
notations, especially the lack of formal semantics, providing for the use of pow- 
erful simulators and code generators such as those currently available. Project 
partners are already involved in OMG standardisation activities, and based on 
the project results they will propose UML standard improvements totally com- 
patible with the project solutions. 

3 End User Requirements Synthesi^il 

The subject of this session is to describe requirements on real-time concepts 
and modeling to develop real-time embedded systems. Most of the requirements 

^ Section coordinator: N. Voros - INTRACOM SA. Other participants to the 
session presentations: J. Aubry - PSA, M. Larborn - MECEL, E. Wohlgemuth - 
DaimlerChrysler, , J. E. Smith - Mercury Computer Systems Inc. 
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concerns modeling, but requirements on coding, verification, validation and tools 
platform have also been discussed. They provide a global outlook of ends users 
requirements. 

Four points of view have been presented: AIT-WOODDES project, SCHNEI- 
DER ELECTRIC, DaimlerChrysler, Mercury Computer Systems Inc. All of 
these point of views are presented here after. 

Globally needs presented for the AIT-WOODDES project and by SCHNEI- 
DER ELECTRIC have a lot of convergences. Additional needs identified from 
an other car builder company, DaimlerChrysler. Similarly, Mercury Computer 
Systems presented a complementary point of view on the development of high 
performance embedded systems. 



3.1 Schneider Electric Point of View (by I. Michard) 

Schneider Electric is strongly concerned with object-oriented approach. The 
main goal is to develop and use some extensions to UML so as to cover Real- 
time software which is a particular case of great interest as far as Schneider 
Electric products are concerned. In particular, the analysis presented during 
the workshop concerned equipments supplying high, medium and low voltage 
to transform and distribute electrical power all the way down the chain from 
power plants to end users. Schneider Electric also builds automation systems 
and associated components for the industry. Their main business needs for UML 
& Real-time extensions are similar to these motivating the AIT- WOODDES 
project: 

— To reach the highest level of quality and safety requested for our products 

— To increase productivity and reduce time to market 

— To improve communication within the project team 

As a central organization, their corporate needs are: 

— To manage the teams skills improvement in software engineering 

— To rationalize and promote the investments on software engineering 

Related to their business and corporate needs, they have been thinking of 
what a good modeling technique is in terms of technique and development pro- 
cess. Some of their criteria are the following: 

— Technique: efficient notation, standard notation, help for modeling and vali- 
dating real-time architecture, specification of behavior (e.g., with state dia- 
grams), modeling periodic tasks (e.g., with timers) as well as asynchronous 
tasks (e.g., through events), compact code generation, simulation and gen- 
eration of test cases... 

— Process: support for the entire engineering cycle, straightforward documen- 
tation of the model, help for maintenance and add of new functions, incre- 
mental development, reuse of a model 
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3.2 AIT-WOODDES Requirements on System Modeling 

The presentation provided by N. Voros (INTRACOM) has described the neces- 
sary modeling elements to specify the characteristics of the systems to develop 
and to describe the solution. It is the result of a common work of the end users 
of the AIT-WOODDES projects: PSA (J. Aubry), MECEL (M. Larborn), IN- 
TRACOM. Each end user development process presents its own specificity, but 
generic activities can be identified and organized according the following generic 
activities: 

~ Analysis: it consists in requirement analysis and system analysis. The first 
point is to extract requirements from customers or users specifications. Then, 
these requirements are complete and structured. They are translated in more 
defined and rigorous models, to describe services, interfaces, communication 
and high level behavior. A first logical partition is proposed. 

— Design: analysis models are detailed, in order to propose a design solution. 
The structural model is mapped on physical architecture. At the end of 
design activities, all low-level components are identified. 

— Detailed design: Each low-level components are defined (control algorithms 
or detailed behavior), and mapped on software structure elements (tasks, 
threads, queues...). And the end of detailed design, real-time implementation, 
i.e. real-time software architecture, is completely fixed. 

— Implementation: Software implementation consists in code generation and 
unit-level testing. 

— Integration: The first level of integration is low level components integra- 
tion, then upper level components, and so on until to obtain the complete 
application. At each step of integration, integration testing is realized. 

— Final validation: Final validation is performed to ensure that the complete 
application, and so the final product, conforms to initial requirements. 

— Requirements management: The objective of requirement management is to 
organize requirements and to track them in all the different documents and 
models produced during the development cycle, in order to check that all 
requirements have been met. Another point is to manage all requirement 
changes. 

— Verification and validation: At each stage of development cycle, the stage 
results are checked to ensure their consistency, their correctness, and their 
conformity to requirements. 

Because, targeted applications are real-time applications connected to an 
external and dynamic environment, the requirement analysis presented during 
the workshop has focused particularly on all concepts needed to represent time. 
These modeling features are necessary to perform timeliness, schedulability and 
resources consumption analysis. They concern representation of time progress 
(explicit timers, models of time), time constraints (deadlines), timing charac- 
teristics (periods, execution time), resources description (logical, physical and 
software architecture) and utilization (components mapping, synchronization). 
User needs description has been organized on the four following points: 
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— Models of time: to allow time properties definition in models, various models 
of time have to be provided, needs on time models depending on application 
services, devices, architecture... In particular, the model must specify on 
which category it is based: 

• Relative or absolute time 

• Universal time, local time, processor time, mission time (local time = 
universal time -I- time zone offset; processor time = time local to the 
processing node; mission time = time since the start of the system ac- 
tivities) 

• Continuous or discrete time (continuous time is a facility to manipulate 
time with infinite resolution and without synchronization problem due 
to resolution differences between clocks). 

Each model of time presents its resolution, that is the unit of time that can 
be measured through that model. Its also necessary to be able to make numeric 
comparisons and calculations, for instance to determinate lateness, earliness, 
duration, interval, accuracy or relationships between different models of time. 

— Period: to describe periodic occurrences, needed parameters are: period 
value, or frequency value; tolerance, i.e. variation around the period value, 
within the period; period number, if the number of periodic execution is 
limited. 

— Inter-arrival time: in order to make schedulability analysis of system pos- 
sible, its necessary to characterize aperiodic occurrences with features like: 
minimum inter-arrival time (i.e., minimum time between two consecutive 
occurrences); maximum inter-arrival time (i.e., maximum time between two 
consecutive occurrences); average inter-arrival time or average rate in a 
period, with dispersion statistics; dependencies among occurrences (for in- 
stance, this feature is used when a message arrival provokes another message 
arrival) . 

— Deadline: for an event-driven action, a deadline is the maximum time be- 
tween the stimulating event and the resulting reaction; for a time-driven 
action, a deadline is the latest point in time that the action must occur. 
Deadline is described with: a deadline value; a “hard” or “soft” attribute (a 
“hard” deadline is a deadline that is essential to respect, a missed “hard” 
deadline is considered as a system failure; a “soft” deadline can be occasion- 
ally violated, “soft” deadline can be qualified with a tolerance, i.e., autho- 
rized mean lateness). 

— Execution time: action execution time is the time this action takes to execute. 
Its an essential data to make schedulability and timing properties analysis 
possible. Execution time is more often calculated by making real measure- 
ments. In this case, context of measurement is important. Therefore, needed 
features are: minimum execution time, maximum execution time or worst 
case execution time (WCET), average execution time (with statistical prop- 
erties), measurement context (platform, compiler...). 

— Concurrency: most of real-time systems need to support simultaneity in 
processing. The number of stimuli is important, and these stimuli are usually 
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independent from each other, which implies concurrent activities to generate 
reactions. Requirements concerning concurrency are: to express concurrency 
between activities; to model synchronization between concurrent activities. 

— Explicit timer facilities: its necessary to have facilities to use time concepts 
in application modeling. Needed services are: starting time initialization, set 
and reset options, start and stop options, models of time options. 

The discussions following the presentation underlined that, even if current 
UML standard (1.3) contains some notions of time, their a clear lack of both 
high level and well defined timing concepts (such as these mentioned in the 
presentation) and of the time semantic it self for date used in UML diagrams 
and of their impact on the execution semantic of the behavior diagrams (sequence 
diagrams, state machine diagrams, etc.). 

3.3 Additional Needs on Time Modeling Identified by 
Daimler Chrysler 

The position paper submitted by F. Wohlgemuth and P. Hofmann from Daim- 
lerChrysler has focused his presentation on one additional need not completely 
discussed previously: the necessity to associate probabilistic features to timing 
specifications. In introduction, the context of the automotive market have been 
set. This industry produces huge volume of products ( 37 M of cars) which is very 
cost sensitive due to the market competition. Electronic systems are constituted 
of networks of 3 to 50 computing units. Their amount of functionalities and of 
computing units is continuously increasing. In addition, from PSA feedbacks, it 
must also be underlined an other very important point of these systems: their 
very high variability. Indeed, a same function can have a lot of different im- 
plementations depending of the car model on which it is integrated and during 
the life time of a model, a same function can evolve a lot and be implemented 
with very different solutions, some of them being not known when specifying, 
designing and developing the function. And, finally, most of the functions are 
real-time functions with a majority of “soft” real-time functions. These “soft” 
real-time functions require new development and validation techniques. In par- 
ticular, F. Wohlgemuth underlined that it is necessary to obtain proven answers 
to schedulability questions, to be able to give detailed figures for latencies and 
execution times and to have extensions able to handle networked environments. 

He illustrated this point by presenting a scenario: assuming that you are 
developing an electronic network managing a comfort function for the car and 
that you are able to define the scheduling parameters (the set of tasks, their 
period and deadline constraints, their execution time properties...). Assuming, 
now, that a timing analysis provide the result that your system is not schedu- 
lable, even with optimal distribution among the network. How to react to this 
problem ? 

— by increasing the resources ? This is not acceptable due to the correlated 
increase of the costs... 
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— by reducing the functionality ? This is not acceptable, because it leads to 
the risk of failing the market acceptance... 

Conclusion is that the problem must be analyzed more in details. In partic- 
ular, by answering to the two following questions: 

— What are the critical paths (that lead to the unschedulability of the sys- 
tems)? 

— How often does this situation happen (i.e., the application executes one of 
these critical paths)? 

In addition, he insists on the need to obtain “proven” answers on these ques- 
tions. In order, to tackle this problem, DaimlerChrysler investigates a modeling 
approach using probabilistic defining of the timing features of an application 
[GaLi99] in association with design and implementation solutions hiding the 
distribution aspects to the developer [LEKH98] . They will use as inputs for the 
analysis probability distributions of the task periods and of their execution times. 
An they will obtain as output probability distribution of runtimes of end-to-end 
scenarios. 

However, during the discussions following the presentation it has been stressed 
that this approach requires to build new modeling formalisms and technical so- 
lutions supporting it. In particular integration into UML formalism and tools is 
clearly not immediate. 

3.4 Mercury Computers Point of View on Needs for High 
Performance Applications 

Point of view presented by J. E. Smith is quite different from the others due the 
particular application domain that is targeted: the domain of embedded systems 
supporting high performance computing applications (e.g., defense or medical 
applications). To improve their development process a particular attention is 
made at this time on possibilities of component reuse. This has leads to the 
integration of UML for high level modeling of the applications. However, efficient 
development of these applications requires a software environment that provides 
an integrated environment with common APIs, libraries and tools for a real- 
time heterogeneous multicomputer that delivers both max system performance 
and application productivity. In particular, this implies to have a single- system 
model regardless of number, type or configuration of processors, with a single set 
of system and algorithm APIs and with a common development environment. 
This would minimize learning, debugging and porting effort with maximizing 
reuse. Main difficulties identified in current solutions used at Mercury Computers 
relies on the diversity of dedicated tools and methods used at the several stage 
of development of such applications: 

— Application structure is expressed efficiently with UML models, 

— Application deployment on a distributed architecture is facilitated by the 
use of CORBA solutions 
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— Parallel algorithms are usually specified through data fiow based models 

— Some functions are specified with mathematical (physical) continuous models 
(e.g., with Mathlab) 

— Some other dedicated graphical languages are used depending of the appli- 
cation domain (e.g., Navy graphical Languages such as ACOS, EGOS, PGM, 
UYS1/2,SPE; commercial graphical languages like Autocode, PGM...) 

Links among these several development paradigms, models and tools are very 
poor: 

— UML models can generate IDL interfaces for GORBA implementation, but 
deployment architecture remains poorly supported by UML and developers 
need to program by hand some essential parts of the application behavior 
such as object initialization, message exchange, synchronization... 

— There is no relation among at this time between UML modeling and data 
fiow based models 

— Gode parallelizing techniques are applied on the application source code, 
without links with the application models. Moreover, the developer compe- 
tencies required to work on this point are very specific and hard to find. 

— There is no connection at this time between UML models and mathematical 
continuous models or the other domain dedicated notations... 

In conclusion, some of the main directions of work mentioned to solve these 
problems are the following: 

— Gombine communication (e.g., UML) and computation model (e.g. data fiow, 
mathlab...) 

— Integrate performance point of view in balance with requirements expressed 
in the models and in regards with several implementation solutions and costs 

— Achieve specification reuseability cross each conceptual paradigm and library 
source 

3.5 Conclusion on UML ad Equation with User Needs for Modeling 
Real-Time Embedded Systems 

To conclude this section, we can underline that more and more end users want 
high level modeling concepts to express timing constraints or properties of the 
system they want to develop or to use. If these concepts (deadline, periods, etc.) 
are common in the real-time domain, clearly current proposals of UML are not 
sufficient, both too poor and too informal. On last point work performed at 
the OMG for the REP “Profile for Performance, time and scheduling” should 
provide a first step of clarification of the semantic of time in UML. But at this 
moment, it is not planed to include high level concepts nor in the standard, nor 
in this profile. 

In addition, a particular interest has been mentioned on integration of proba- 
bilistic definition of time features. This implies that time concept definition must 
be both formal and open in order to be able to extend or specialize its definition 
in order to support this kind of approach. 
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Finally, last presentation has also identified a need of integrating to UML 
(or interfacing with) additional modeling paradigm: data flow modeling and 
continuous mathematical models. 

4 UML Specialization for Real-TimeU 

This session was focused on extensions of UML formalism for dealing efficiently 
with real-time specificities when developing embedded systems. Six presentations 
have been made on this subject. 

Two of them was focused on the description of work in progress at the OMG 
on the following subjects: definition of standard mechanisms to extend or spe- 
cialize UML for specific needs or domains, i.e., the notion of UML profile; and, 
definition of an action language semantics allowing to describe actions performed 
by an application at the model level instead of programming them directly at the 
implementation level with existing programming languages. Both presentations 
have been performed by I. Ober from Telelogic, France. 

Two others was presenting UML extension proposals for the real-time do- 
main: the description of the Rhapsody framework (by R. Rinat from I-Logix) 
for design of real-time applications and a proposition of a structured use of UML 
state machines (ACCORD/UML approach, by S. Gerard from GEA-LETI) to 
represent application dynamics without mixing algorithmic details of processing 
with specification of the logic of control of the applications objects. 

A fifth presentation, performed by I. Michard from SGHNEIDER ELEG- 
TRIG, as set the context initial results of a comparative study on the respective 
advantages of SDL based modeling and UML based modeling for real-time em- 
bedded systems of SGHNEIDER ELEGTRIG. 

The last one, performed by J-P Babau from LSI laboratory of INSA/Lyon, 
discussed of the necessity to evaluate performance of different implementation 
models from a same generic UML model of a real-time application. 



4.1 To the Definition of UML Profiles for Real-Time 

Telelogic is one of the tool editor and vendor of real-time UML environments 
that is very active at the OMG on the standardization process, in particular, for 
subject concerning real-time concerns integration into UML. 

In this context, I. Ober participates to several working groups on the subject 
such as RFP “Profile for performance, time and scheduling” or RFP “Profile 
for action semantics” and also on works on the standardization of the notion of 
profile itself. 

At the time of the workshop, work on “Profile for performance, time and 
scheduling” was not sufficiently advanced to allow an interesting presentation of 

^ Section co-ordinator: F. Terrier - CEA-LETI; Other participants to the session: I. 
Ober - Telelogic, S. Gerard - CEA-LETI, J.- P. Babau - INSA/Lyon, R. Rinat - 
I-Logbc, I. Michard - SCHNEIDER ELECTRIC 
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the current status of the proposal, but now a first draft is available at the OMG 
[OMG-PTS] . So workshop presentation have been focused on “Profile for action 
language” and on the necessity to have a more precise definition of the notion 
of “Profile” in UML. 

The answer on RFP “Profile for action semantics” is now freely available on 
the OMG web site [OMG-AS], so its content will not be presented here. However, 
some of the main points of the discussions following the presentations merits to 
be given. First, it was clear for everybody, that the proposal is quite complex (the 
volume of the proposal is similar to this of the UML 1.3 standard specification 
itself...) and that its relation with existing programming models or languages is 
not totally obvious. Second, it has been underlined that the question of time has 
been put away from the current proposal, and, thus, that it will not solve the 
question of having of formal modeling support to specify actions sequences and 
interactions in real-time systems. Finally, it has been also pointed out that, it is 
a little strange that such modeling specifications could be considered only as an 
optional extension of UML (that is the case, if it remains only a particular profile) 
and not an important part of the core of the UML standard itself. Indeed, having 
precise semantics of UML models including dynamic behavior specifications of 
concurrent systems requires a formal definition of the semantic of the actions 
specified in a given model (e.g., of the action sequences attached to the transition 
specifications in UML state machines). 

Goncretely there is discussion at OMG on what can and must contain a pro- 
file to be a consistent, efficient and usable extension or specialization of the UML 
standard. In particular, it is generally agreed that a profile is defined through the 
definition of specific tagged values add on standard UML elements, of additional 
constraints among modeling elements and of stereotypes refining semantics of 
some modeling elements (a stereotype can be seen as a structured use of a set 
of particular values tagged values and constraints applied on a same modeling 
element). However, it is also often considered that this is not sufficient to provide 
really usable profiles. In particular, it is suggested [Desfray] that a profile con- 
tains also the following elements: the list of the modeling elements that can be 
used in the context of the profile (only a restriction of UML standard modeling 
element can been allowed for a particular use); specification of the choices taken 
on the semantic variation points kept open in UML standard and precisions on 
the known semantic weakness of UML (ambiguities, etc.); additional notations 
attached to the extended modeling elements, translation, validation and presen- 
tation rules of models using the profile. Works performed for UML 2.0 proposal 
should answer to these points. 

Goncerning the definition of profiles for the real-time domain, I Ober analy- 
sis of the question is described here after. The use of object oriented techniques 
in the area of real-time is increasingly demanded, although it faces some im- 
pediments mostly due to the fact that the techniques currently used in the 
object-oriented world are not well coupled with the practices of the real-time 
world. It is interesting to notice some apparently contradictory feelings of the 
real-time community with respect to UML. On one hand people seem to consent 
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that UML could offer the necessary means to perform analysis and specification 
while taking advantage of the fact that it is a widespread, standardized language, 
and thus a good communication mean. On the other hand UML is considered 
too general to be used as such for specifying real-time systems. 

UML is not well fitted for being applied to real-time systems due to two main 
reasons, not necessarily disjoint: 

— First, UML lacks the basic concepts needed to deal with specific real-time 
concepts. Although it has a weak concept of time (which is rather a place- 
holder for a desired concept of time), it does not have the basic building 
blocks needed in real-time systems: clocks, scheduling policies, priorities, 
etc. 

— The other class of problems in applying UML to real-time problems is caused 
by the lack of precision of UML. While this increases the generality of UML 
and makes it applicable to a wider area of domains, it is not suitable for 
real-time systems, whose characteristics demand precision. Precision could 
be thought at various levels. The lowest level of precision requires that all 
the concepts are clearly defined and that no contradiction occurs between 
the definition of these concepts This is the minimum amount of precision to 
ask from the UML in order to be used in real-time systems. The highest level 
of precision of UML corresponds to the existence of a formal definition of its 
semantics, that would serve as a basis for proof, verification, simulation and 
testing of systems specified with UML. One of the questions the real-time 
community should answer is on the level of precision it expects from UML: 

• the minimal one - that would permit more generality while being precise, 
thus giving place to nuances (e.g. we could have a low level of precision 
when defining the notion of time, without specifying whether we have a 
continuous or discrete time or whether is global to the entire system, or 
local to each package, etc.); 

• the maximal one - which gives less place to alternatives, but allows the 
existence of powerful tool support (e.g. in this case it should be clear 
whether we have continuous or discrete time and whether the time is 
global to the entire system or not, etc.); 

• an intermediate solution (and if this is the chosen case, we should define 
precisely what does it means). 

The UML is a general purpose analysis and design language, though it has 
some deficiencies that rise problems even when applying it to general, domain 
independent problems. Therefore as such it cannot provide a solution for all real- 
time domain specific problems. One of the keys to overcome the UML deficiencies 
and to make it suitable for real-time is to define a “tuning” for real-time applica- 
tions. The first attempts to provide a good coupling between UML and real-time 
were proprietary, but for the moment they are the only ones operational. We can 
cite: 

— Rhapsody solution for UML and RT coupling 

— ROOM solution, which defines ROOM in terms of a UML profile 
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— The recently released SDL-2000, that has an annex Z.109 which describes 

SDL as an UML profile. 

OMG has initiated a work for a UML profile for real-time. This approach has 
the advantage that it should take into account the concerns of people involved in 
the real-time industry, while being driven by the UML community. The drawback 
though is that trying to remain general enough to be applicable to a wide area 
of problems, it is not expected to offer the answer to all open questions of the 
real-time field. 

I Ober position is that the UML should be adapted to real-time through 
profiles, since they are the standard way to add to the UML domain-specific 
concepts and constraints. It could be acceptable that the UML real-time profile 
be in fact a family of precise profiles, each of them designed for a specific sub- 
area of real-time systems. This whole family of precise real-time profiles should 
be derived from a more generic profile, whose extensions to the standard UML 
are rather on the vocabulary and basic constraints. The dedicated profiles would 
be refinements of the generic one in terms of precise meaning added to real-time 
concepts, without contradicting the constraints imposed in the generic profile. 
A specific and precise profiling (together with the generic profile it refines and 
the UML it extends) should fulfill the above mentioned goals of completeness 
and precise definition. Completeness requires that all the concepts to be used 
together with that profile must be contained in the profile. The precise definition 
goal requires that all the concepts (either real-time specific or not) have a clear 
semantics. 

The actual means to describe the precise profiles as a refinement of the to 
be defined UML RT profile, are open to discussion. One possibility would be to 
define inheritance relationships between profiles. A child profile would inherit 
from its parent (s): 

— all the classes it contains (i.e. all the concepts defined by the parent profile), 

— all the newly added stereotypes and constraints, 

— all the semantics defined for its parent. 

This solution requires a careful definition of the actual meaning of inheritance 
between profiles. An alternative approach would be to simply use dependency 
relationships between profiles. 

4.2 A Framework Based Approach for the Development of 
Real-Time Applications with UML 

Next presentation describes the solution adopted by a commercial tool, Rhap- 
sody from I-Logix, for developing real-time application in association with UML 
modeling. The approach, described by R. Rinat, is based on the use of a ded- 
icated framework providing an object oriented support of the concepts needed 
to implement real-time applications. A framework is a collection of collaborat- 
ing classes that provide a set of services for a given domain. The are several 
advantages to using frameworks, the most important of which may be: 
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— The target system need not be written from scratch since it reuses elements 
of the framework. 

— Frameworks structure the design of the target system by providing a set of 
pre-defined abstractions, given by the classes in the framework. These classes 
provide architectural guidance for the system design. 

— Frameworks are open designs because their classes may be customized via 
subclassing. 

Rhapsody framework, called OXF, contains a set of useful real-time abstrac- 
tions which structure the generated code and give concrete meaning to UML 
concepts. Regarding to simple code generation from the models this makes it 
easier for developers to understand the generated code. Other advantages are 
that: 

— Significant portions of functionality are factored out into the framework 
classes, so there is less need to generate specific code. This also eases the 
task of understanding the code. 

~ The Framework has an existence of its own, which is independent of the code 
generator. Its classes may be used outside the code generation process, in 
user-class implementations, or in any other way desired. 

— Framework elements can be customized via inheritance to fit the developers 
specific needs and to add particular behavior to the generic one provided by 
default by the framework. 

R. Rinats presentation of the framework gives the main UML concepts se- 
lected to implement real-time application and describes the interpretation choices 
made to obtain a precise semantic of them. This concerns, in particular, the UML 
concept of active object: it is defined in UML as “an object that owns a thread 
and can initiate control activity” . This general definition is given concrete mean- 
ing in the framework by the OXFActive class. Objects of this class own a thread 
of execution, and have event dispatching and timeout scheduling functionality. 
They contain code that manages a single plain event queue and executes a never- 
ending event-loop, taking events from the queue and injecting them to the target 
instances. 

In addition, the framework introduces an other concept: reactive objects that 
can react to events, i.e. it is an event consumer. These reactive object have an 
associated event manager, which is an active class. It is at their level that the 
dynamic behavior of an application is specified. This is performed by attaching a 
statechart to the reactive objects specifying in the same statechart the message to 
which the reactive object will react, in which conditions and haw is implemented 
the object reaction (each UML class that has a statechart is considered as being a 
reactive class). After introducing these two concepts, the presentation described 
the communication protocol supported by the framework. The mechanisms are a 
little complex and can not be completely explained here. Roughly, the principle 
is that it is the active classes that control the event dispatching. However, only 
event used to trigger transition of the reactive object statecharts are managed 
and processed by the active object. Simple operation calls are not managed by 
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the active classes. This means that operation calls always execute on the callers 
thread while reaction on signal receipts are processed by the active object thread. 
Use of operation calls requires to put specific concurrency control instruction 
in the reactive object code to ensure that no conflict can appear between the 
execution of the operation code and the processing of the statechart actions of 
the passive object. Normally, operation calls are not used as trigger event in 
the reactive object statecharts, but it can be done, in this case the operation 
call is managed as an incoming event by the statecharts but executed in the 
callers thread. Else, two other kinds of events can be used to defining transition 
triggering in the reactive object statecharts: signal receipts and timers. They are 
processed on after the other in the thread of the active object responsible of the 
event dispatching. 

In addition, the framework provides UML definition and implementation 
of resource protection: semaphore and mutex classes and, also, the concept of 
protected class that allow to defined protected operation by setting their con- 
currency attribute to guarded. 

In conclusion, as R. Rinat pointed out at the end of its presentation, there is 
still much work to be done regarding real-time UML: the recent RFP for schedu- 
lability, performance, and time issued by the OMG identifies the most important 
issues that need be worked on. In addition, there are several existing concepts 
that are still under discussion, such as the concept of active class, the precise 
semantics of state machines, variants of sequence diagrams, and so on. These 
works will lead to evolution of current tools proposals for supporting real-time 
development from UML models. An “open-minded” customizable architecture 
for implementation code can be thus considered as a good starting point for the 
future. 

4.3 Protocol State Machine 

The third presentation focused on the use of UML state machines to specify 
real-time systems behavior. It was titled Structured use of state diagrams for 
real-time systems design’' and submitted by S. Gerard & F. Terrier of GEA-LETI 
and N. Voros & G. Koulamas of INTRAGOM. The objective of the proposal is 
to preserve the common object paradigm, which manipulates the object at two 
levels: its interface and its implementation. 

Goncretely, in UML modeling, the object interface can be associated to the 
information provided in the class diagram, i.e., its operations and its attributes. 
However, almost all modeling extension of UML for real-time emphases so much 
the modeling of the object behavior that this behavior contains both specifica- 
tion of overall object control and of implementation of the operations it performs. 
This leads to complex state diagrams mixing different concerns such as algorith- 
mic specification of the object operations and specification of general control of 
the object state. Moreover, these king of state diagrams generally miss the rela- 
tions with the basic object interface, i.e. the list of its operations and attributes. 

To avoid this confusing use of the state diagrams in an object oriented ap- 
proach, the authors propose to use the statechart diagrams at the two allowed 
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contexts defined by UML standard: the classifier context (like, classes or use 
cases) and the behavioral feature context (like operations or methods). In the 
proposed approach, called ACCORD/UML, class behavior is described through 
a restrictive and specialized use of UML statecharts largely based on protocol 
statecharts as defined in UML semantics and operations behavior is described 
via an alternate view of statecharts focused on actions performed when execut- 
ing the operation. This last point is introduced not to define a proper action 
language but simply because of the lack of action language in UML (at this 
time). 

Moreover, to facilitate reuse of object specifications, ACCORD/UML con- 
siders two points of view (abstraction) for the specification of the object state 
control: the protocol view and the triggering view. The first one is independent 
from the real-time aspect of the object behavior, while the second one correspond 
to its real-time feature. 

The protocol view of a class intends to describe all the possible behaviors of 
a class instance when it receives a message in the form of a called operation. 
This specific view allows the designer to specify which operation calls are pos- 
sible for each state of the object. Indeed, the protocol view describes “what a 
class can do”. The statechart describing the protocol view of an object refers 
only to transitions having only on the left-side a trigger event of type CallEvent 
with possibly a guard and having a right-side being empty. Actually, the ac- 
tion sequence specification is implicit: when such a transition is fired everything 
happens as if an internal event was sent triggering the execution of the method 
implementing the operation associated to the call event which has triggered the 
transition. The behavior specified within a protocol statechart is available re- 
gardless of the objects type: standard or active object. 

For triggering view, it proposed to use the UML additional event types {Sig- 
nalEvent, ChangeEvent, TimeEvent, CompletionEvent) to trigger transitions. In 
this approach, this can be performed only for active objects, because it implies 
their processing concurrently with the rest of the system. This will define the 
reactions of an object (a) when the object receives signals that are declared to be 
sensible, (b) when it reaches a particular state (specification of completion tran- 
sitions), (c) when it detects a change in the system through a specific boolean 
expression (ChangeEvent) and, (d) when a timer expires. The triggering view 
of an object focuses on “what a class must do” . The semantics of the triggering 
view transitions are based on the principle of protocol-transitions i.e., a tran- 
sition firing involves the execution of the method combined with an operation. 
As opposed to protocol-transitions, the action sequence of triggering-transitions 
has to be explicitly specified, and must to always be a single action of type 
CallAction. The triggering view of an objects behavior is not independent of its 
protocol view: a transition in the trigger view from state SI to state S2 with 
the label, evt [g]/opeName(...), is called “lawful”, if the protocol view defines a 
transition from state SI to state S2 with the label opeName(...). Actually, these 
two views are two abstractions of the class global behavior, each one focusing 
on a particular aspect of object behavior. Real-time active classes can also be 
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easily reused, either as real-time active objects or as standard objects. In the 
latter case, the behavioral aspect of the real-time active object specified in its 
triggering view is inhibited. 

After having specified the class control logic, the designer models the behavior 
of the class operations. Up to now, in UML there is no well-defined way to specify 
algorithms. Since a statechart may be used to specify behavioral features such as 
methods i.e. implementation specification of class operations, ACCORD /UML 
elaborates the use of statecharts for defining the behavioral specification of ob- 
jects operations. More specifically, methods are described through a specific use 
of statecharts decomposition in sequences of UML elementary actions : send ac- 
tion, call action, create action, terminate action, destroy action, return action 
and assignment action. The actual goal of this approach is not the description 
of complex computation algorithms, but to underline the synchronization points 
between the real-time objects of the application. 

This work has been evaluated on several application cases and, in particular, 
on a case study issued from the telecom domain and provided by INTRACOM 
which is described in a white paper of the AIT-WOODDES project [GVCT2000]. 
In conclusion, S. Gerard shows the correspondence between the usual use of state 
machine in real- time UML extensions with this approach. He demonstrates that 
the proposed use of statecharts for specifying object behavior at three levels 
(object control, object reactions, operations) includes the previous ones and 
provides more comprehensive and reusable models. 

4.4 Evaluation of SDL and UML Based Approaches for 
SCHNEIDER ELECTRIC Developments 

Presentation of I. Michard gives the first stage of results obtained when eval- 
uating UML and SDL approaches for the development of next generations of 
electric systems of SCHNEIDER ELECTRIC. These evaluation are motivated 
by the need to just now an object oriented techniques in order to increase pro- 
ductivity and reduce cost and time to market. However, because a real-time 
standard profile is not available in UML, yet, they need to work with existing 
solutions. Two industrial environments have been chosen: Rose-RT from Ratio- 
nal supporting a UML based approach for real-time and TAU from Telelogic 
supporting an SDL based approach. 

A first evaluation of Rose-RT has been performed for medium voltage equip- 
ments (e.g., protection, monitoring and control units). Implementation of the 
products uses embedded software programmed in C language with real-time op- 
erating system architectures. Goals of the evaluation focused on the adequacy 
of UML-RT for automation software, capacity of assisting real-time architecture 
and design phases, capacity of simulation and code generation and on a com- 
parison with the standard development process. A second evaluation stage has 
been focused on the comparison of UML-RT and SDL approaches. It concerns an 
other category of equipments: low voltage equipments (e.g., molded case circuit 
breakers, power circuit breakers, measurement and control units). This prod- 
ucts use also real-time embedded software programmed in C language C with 
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real-time operating system architectures. Goals of the evaluation: comparing 
both techniques by re-engineering an existing software, capacity of improving 
real-time architecture and design phases with a CASE tool, capacity of use of 
an incremental process by adding an evolution on the application specification. 
The main features of these approaches being identified at this time are: 

- for UML-RT (Rose-RT): 

• there is a real step between notation and use of it in an efficient method; 

• it requires to choose a priori types of problems to be solved by modelling 
when notation is wide-range. In particular this needs to be able to select 
the valuable sequence diagrams among the possible flows 

• it is essential to identify the type of the objects of the system: are they 
defined by a capsule or by passive class? This is quite critical because it 
has an important impact on the final real-time architecture performance 
and it requires an intensive use of simulation 

• it requires to reflect if tasks should be modeled as periodic or asyn- 
chronous. This requires to define what is the real user need. 

• it supports modeling of dynamic object creation 

• deployment in RT tasks is achieved late in the modeling process giving 
more flexibility in the design process 

— For SDL (TAU):it seems to be not well-suited for the analysis phase. It would 
be probably interesting to use UML at this stage : use UML. However, this 
require a clear definition of the connection between UML and SDL notations. 

• it is not suitable for modeling passive classes 

• the state diagram is a flat model which mixes the specifications of the 
states and of the operations themselves 

• description of a state machine is performed only at process level, not at 
the bloc level 

• it allows to model the launch of processes at initialization of the system 

• it requires to dispatch the processes in tasks providing a low flexibility 
in the design 

Some technical discussions have followed the presentation to identify precisely 
the difficulties encountered during the evaluation. In conclusion, it is clear that 
both solutions are not satisfying and require for the users the definition of the 
best way to use them waiting more advanced and efficient solutions will be 
provided on the UML standard. 



4.5 Performance Analysis of Implementation Models 

In addition, a study performed by Jean-Philippe Babau and Jean-Louis Sour- 
rouille of the LSI Laboratory of the INSA-Lyon (France) has been presented. It 
was titled ^^Multi-Tasking Implementation for Object-Oriented Design'^ and con- 
cerns the analysis of the implementation models and paradigm on the efficiency 
of the real-time applications developed from UML modelling. In particular, they 
have stressed the inherent concurrency of real-time systems environments and. 
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thus, their usual implementation through multitask models and supports. Be- 
cause a same model can have different implementations they have underlined the 
necessity to be able to formally define an implementation model at a level al- 
lowing to perform performance analysis. For that they propose to use a resource 
based model using explicit definition of task, synchronisation resource, informa- 
tion exchange, etc. However, as they mentioned, this point can become partic- 
ularly difficult for object oriented models proposed by commercial or emerging 
prototyping environments where some low level implementation concepts are 
hidden by higher encapsulating concepts. For analysing implementation perfor- 
mances through the several possible execution models, the authors proposed to 
use the following criteria: 

— Complexity: this criterion corresponds to complexity of generated code. It is 
characterized by the number of real-time elements like tasks or semaphores. 

— Size: this criterion corresponds to the size of generated code. 

— Real-time performances: this criterion corresponds to the responsive time 
to an event. It is characterized by blocking time due to the chosen model 
(critical sections induced by the model). 

— Real-time scheduling: this criterion characterized, for an implementation, 
the possibility to use on the implementation model the classical real-time 
scheduling algorithms like Rate Monotonic or Earliest Deadline. 

— Real-time policies: this criterion characterizes the ability of the model to 
express real-time policies (fault tolerance policies, adaptation policies,) at 
the design stage and to implement it. 

— 00 advantages: this criterion is used to qualify the benefits of an 00 ap- 
proach for implementation model like the reusability, composition, and sub- 
stitutability. 

— Architecture: this criterion is defined to characterize the easiness of integra- 
tion of generated execution model in a distributed architecture in opposition 
to a monoprocessor architecture. 

Although, the criteria are these one usually met for real-time application 
analysis, independently to an object- oriented modeling, they stressed the ne- 
cessity to have formal solutions allowing to analyze UML models with the usual 
criteria of the real-time domain and to be able to re-interpret the results of clas- 
sical analysis tools at the level of the object model itself (i.e., the UML model). 
This point has to be considered in connection the work performed at the OMG 
for the RFP called “Performance, time and scheduling” . 



4.6 Conclusion 

This session has pointed out the gap between the wishes (requirements) of the 
end users and the currently available solutions. It has presented several research 
directions trying to make more efficient the modeling and development of real- 
time embedded systems. In particular, four axes of work have been pointed out: 
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— Definition of an action language semantics integrated to UML 2.0 

— Definition of profiles to define how to use UML for real-time applications 
and, by consequence, improvement and precision of the notion of profile 
supported by UML standard. It is one of the objectives for UML 2.0 

— Definition of rules of use of UML modeling facilitating the specification (and 
management) of the application behavior (e.g., rules on the use of the state 
diagrams) 

— Development of analysis techniques and formalization of the various imple- 
mentation models to be able to evaluate application performances form its 
high level UML model. 

5 ^ ^ Behavior of Embedded 



In the session Modeling and Verifying Behavior of Embedded Systems with UML 
the participants discussed the relationships between the necessary enhancements 
of UML in order to cope with the development of real-time embedded systems, 
the formal definition of the UML semantics, the outstanding OMG action se- 
mantics standardization, and the tool support for the validation and verification 
of UML specifications and models, respectively. The discussion was driven by 
four position presentations concerning these mentioned topics. 

5.1 Real-Time Extension of UML State Machine 

The first presentation was given by I. Torres (Turku Centre for Computer Sci- 
ence, Finland). Torres et al. are well known in the domain of formal methods and 
its application, in particular to the UML formalisms. The title of the presentation 
was “UML state machine extensions for real-time”. During their presentation 
they mentioned three main issues that have to be tackled in order to extend 
UML for the development of real-time systems. They see three main issues that 
have to be addressed: 

— Additions to the concrete syntax, e.g. methods for specifying timing con- 
straints. 

— Additions to the abstract syntax, e.g. how the new concrete syntax can be 
mapped to existing concepts in the UML meta-model. 

— Definition of the semantics of the concepts in the meta-model. 

They pointed out that it is mandatory to rigorously define the semantics of 
all the UML features which shall be analyzed by automatic verification methods. 
The current state of the formalization of the UML notations is still far from that 
needed both in the number of concepts already handled and in the degree of the 

® Section co-ordinator: U. Brockmeyer - OFFIS e.V.; Other participants of the session: 
I. Forres & J. Lilius - Abo Akademy, S. Gerard - CEA-LETI, A. David - Univ. 
Upsaala 
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formalization. In particular, the community is still waiting for an OMG action 
semantics proposal that fills this gap in the current UML. 

Furthermore, Porres showed that the state-machine dialect as incorporated 
in the UML has already limited capabilities for expressing real-time constraints, 
i.e. by using timers and timeout events. But this is only a very weak mecha- 
nism that essentially allows the designer to express very simple requirements of 
the implementation. This mechanism needs to be strengthened to allow more 
complex requirements and to allow the designer to express performance guar- 
antees. In fact, Porres et al. propose a variety of state-machines for real-time 
that combines state- machine semantics with timed automate. Since many years 
now, timed automata are a well studied and accepted formalism for the speci- 
fication and analysis of real-time systems. Porres et al. have published already 
definitions of UML state-machine semantics and they have implemented a pro- 
totye tool, the vUML tool, that allows to formally verify properties of restricted 
state-machines. They see a way to combine their work with the techniques used 
for timed automata in order to be able to check state-machines with real-time 
restrictions 

It is also clear, that is mandatory to extend other UML formalisms with 
real-time capabilities. These are the diagrams that describe the relationships of 
the objects and their exchange of messages over time, e.g. class diagrams, object 
diagrams, collaboration diagrams, sequence diagrams, etc. 

They conclude that the UML can in principle be used for the development 
of real-time systems, but it still needs many improvements and standardization 
efforts. Before real-time extensions are defined it is necessary to understand 
and to formalize the semantics of the current UML formalisms. The extensions 
can be defined on the basis of these definitions. Porres et al. work on both, on 
the formalization and extension of the UML as well as on the development of 
automatic verification tools. 



5.2 Integration of Hierarchical Time Automata in UML 

The second presentation was given by A. David (Uppsala University, Sweden). 
David et al. have already significantly contributed to the development of formal 
verification methods and tools. Their tool, the UPPAAL tool, is one of the first 
checkers that allows to automatically analyze real-time models. UPPAAL is a 
tool box for modeling, verification and simulation of real-time systems. The 
model used is described as a state-machine with finite control structure, real- 
valued clocks and integers. The tool can be used to check invariant properties and 
reachability properties using on-the-fly techniques. The title of the presentation 
was “Hierarchical timed automata” . They pointed out that already a number 
of real-time checkers exist, but that they can only accept a collection of flat 
automata. David et al. propose a hierarchical model for timed automata. Their 
attempt is to combine the notion of (UML) state-machines with the concepts of 
time automata. With this contribution they add real-time clocks to the UML 
formalism, allowing to analyze timing specifications of UML models. 
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Their contribution is twofold. First, they define and publish a formal syntax 
and semantics of hierarchical automata, which is a prerequisite for the devel- 
opment of automatic verification tools. Second, they will extend their current 
UPPAAL tool in order to support analysis of these hierarchical models. Their 
work closely corresponds with the current efforts of the OMG to define a real- 
time profile for the UML. On the other hand, it is still an open question, how 
the timing properties of single state-machines relate to the overall UML model 
context as given by class and object diagrams. To integrate these ideas into 
the UML formalisms and into an overall design methodology, a process has to 
be defined that allows to specify and to verify related timing specifications of 
interaction diagrams (sequence and collaboration diagrams), class and object 
diagrams, and state- machines. 



5.3 Problematic of Formal Verification of UML Models 

The third presentation was given by U. Brockmeyer (OFFIS, Germany). The title 
of the presentation was “Formal Verification of Object-Oriented Specification 
Models”. They pointed out, that, on the one hand, the UML language is used 
already today in current development processes, but, on the other hand, formal 
verification techniques are not yet part of any regular UML-based development 
approach. This is the case, even if formal verification techniques can aid in 
collecting more complete and consistent requirement specifications, validating 
functional correctness of specification models, and in analyzing timing behavior 
on high-level models. The benefits gained by using formal verification techniques 
are increased quality of design, reduced design times, and reduced costs. 

Brockmeyer et al. postulate that the introduction of formal verification tech- 
nologies into industrial design processes requires highly automatic methods and 
techniques. The technique of model checking is such a mature technique, because 
it is studied and used since 20 years now. A model checker requires as inputs an 
implementation model and a specification model that can be verified. Visual for- 
malisms and languages like UML are accepted by designers and can be used for 
specification and modeling. The inputs for a model checker can be automatically 
derived out of these models. The approach of Brockmeyer et al. can be summa- 
rized as formal verification of UML models based on scenarios. The scenarios as 
specified by designers determine objects that exchange information. The class 
and object models provide information about available services and/or events 
and passive and active classes, respectively. State-machines implement object 
behavior that has to be verified. They do a development of automatic transla- 
tors of object/state-machine models into the model checker input language with 
respect to scenarios. 

They pointed out that four main questions have to be addressed: 

— The missing definition of an OMG action semantics does not allow to de- 
velop and implement a verification environment fully compliant with UML 
formalisms. 
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— The formal definition of the semantics of UML state-machines is mandatory 
for the development of verification tools. The UML state-machine concepts of 
run-to-completion steps, event queues, event dispatching, event processing, 
etc. have to be addressed. 

— The formal definition of the semantics of the interplay of passive/active 
objects is mandatory for the development of verification tools. UML of- 
fers various concepts to describe the interplay. For instance, collaboration 
and sequence diagrams offer the possibility to describe the interplay. Ac- 
tive/passive objets exchange messages over time, thereby respecting some 
communication rules. For instance, some objects can handle incoming calls 
concurrently, while others can only respond in a sequential manner. Also 
important is the question of priorities of calls. It may be necessary, that an 
active object generates a high-priority call to another object, resulting in an 
interrupt of the called object, in order to fulfill some requirement. 

— The UML interaction diagrams shall be used to formalize requirements for 
the verification of object properties. But, these formalism are still too weak 
to express all interesting requirements of objects. The formalisms have to be 
extended in order to be able to express safety and liveness properties. 

Brockmeyer et al. work on all the mentioned topics above. In particular, they 
define a semantics for the state- machines and for the interplay of the objects. 
They already have contributed significantly to the improvement of interaction 
diagrams. They published a very strong variant of sequence diagrams that allows 
to formulate many interesting properties of reactive systems. 

5.4 Test Generation from UML Models 

The fourth presentation was given by S. Gerard (CEA-Leti, France). The title 
of the presentation was “Automatic Test Generation from a UML model based 
on Active Objects”. In contrast to the former presentations, summarized above, 
Gerard et al. try to develop a test environment for UML models. Their objec- 
tives are twofold. First, their intention is to do test case generation on UML 
specifications, where the model is based on active objects, and where commu- 
nication is done via operation call messages. Second, they want to exploit an 
existing prototype (the AGATHA tool). This tools does test case generation 
by symbolic execution, parallel automata communicate via rendez-vous mecha- 
nisms, and the input language is the language of ESTELLE, with interfaces for 
statecharts and SDL. Their overall development criteria is that the test process 
should be fully transparent for the user. The user does have to know anything 
about the AGATHA tool or the ESTELLE language. 

They have to bridge the gap between the rich UML formalisms and the 
input format as accepted by Agatha, which is much simpler than the features 
offered by UML. Thus, they define some restrictions on the UML state-machine 
semantics. For instance, they support simple states and transitions, they allow 
transition triggering by call events only, and they support only one operation 
call per transition. But, more general models can in principle be handled by 
developing a translator. 
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One of their main contributions is the definition of a complex communication 
mechanism, which is based on the notion of active objects and which is used for 
test case generation. Each active object contains an event-queue, a dispatcher, 
and a UML state-machine representing the behavior of the active object. The 
execution semantics of UML state-machines defines an hypothetical machine 
that holds, de-queues, and processes event instances, which is reflected in the 
active object mechanism of Gerard et al. But their still exist many difficulties 
in generating test for UML that comply to the semantics. For instance, the 
integration of a FIFO mechanism, the run-to-completion semantics, and the 
management of deferred events is not easy. Currently, they are developing a 
prototype that implements the test case generation with respect to the UML 
active objects and state-machine semantics. 



5.5 Conclusion 

Each individual presentation was complemented by a short discussion, where 
the speakers discussed questions that relate with the individual presentations. 
The whole session was followed by a more in-depth discussion around the issues 
of UML formalization, extension, and verification. The mains points that have 
been worked out can be summarized as follows: 

— The development of validation and verification tools requires a rigorous def- 
inition of the syntax and semantics of all the UML features that have to be 
tackled. The current state is not sufficient. In particular, the UML standard 
1.3 defines the semantics only informally. 

— A main obstacle is the missing definition of an OMG action semantics. This 
is a limitation for UML tool providers as well as for the development of 
verification tools. 

Many more questions are not addressed by the UML 1.3 standard. For in- 
stance, dispatching of events is not defined, it is not explained how long events 
are on their way from the sender to the receiver, or if events can get lost, etc. 
The interested reader can And many of these open questions. The writers of the 
UML argue that most of these issues need not to be addressed on the model 
level, but only on the level of code generation. This is true to some extend, 
but when developing and implementing formal validation and verification tools, 
these questions clearly have to be solved on the model level, too. 

The capabilities of UML to formally describe real-time requirements are very 
limited today. There is an ongoing request of the OMG for a new profile covering 
real-time and scheduling aspects. But it seems that it will take another period 
until this request will be closed. In the meantime, there will be many attempts 
to bring real-time into UML, but it is open how these relate to the expected 
OMG real-time definitions. 

Some of the UML formalisms have to be extended in order to be used in 
verification tools. For instance, the state- machine semantics should be extended 
with the notion of timed automata. Also, more expressive mechanisms are needed 
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to formulate requirement specifications which have to be verified. For instance, 
interaction diagrams should be extended with features to state safety and liveness 
properties. 



6 Workshop Conclusions 

Even, if all the participants agree on the fact that UML will become the de 
facto standard for modeling applications and that its potential advantages for 
building component based development techniques for real time systems, it is 
also clear for all the participants that a lot of work remains to done in order to 
reach the objectives of both automating, optimizing application implementation 
and of reducing cots and time developments. 

In particular, new UML profiles must be proposed to support higher level 
modeling of application, integration of advanced validation techniques and inte- 
gration of particular needs such as connection with data flow based modeling or 
definition of probabilistic timing features. 

Presentations performed during the workshop have shown that both the re- 
search community and the industry or tool vendors are very active on these sub- 
jects. Incoming conferences and workshop (such as the “Formal Design Tech- 
niques for Real-Time UML” (FDTRT) workshop associated to the UML2000 
conference) will probably provide more and more precise responses. This pro- 
vides a very favorable context to obtain during the next years efficient and 
industrial solution for this particularly important application domain that takes 
a more and more important place in the market of the computer based systems 
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Abstract. The suitability of the object-oriented programming model 
for implementing distributed systems has lead to middleware platforms, 
such as CORBA, DCOM, and Java/RMI. Originally, these middleware 
systems aimed at distribution transparency for application programmers. 
However, distributed systems are exposed to system issues, such as dy- 
namic performance changes or partial errors, which prevent complete dis- 
tribution transparency. Quality of Service (QoS) management addresses 
these system issues. The goal is to add QoS management to the inter- 
actions between clients and services. Support for QoS management in 
distributed object systems is a hot topic of current research which poses 
a number of open questions: How is QoS integrated with the object 
model that emphasizes encapsulation and information hiding? Can one 
bnild generic support frameworks for multiple QoS categories, in contrast 
to specialized, single category systems, such as TAO, Electra, Eternal, 
DOORS among others. Can QoS be viewed as an aspect in the sense of 
Aspect Oriented Programming (AOP) or are other classifications more 
appropriate? This ECOOP-workshop has discussed the open questions 
and aimed at a summary of the state of the art in the field. The work- 
shop stimulated discussions about how next generation QoS management 
facilities can be built into object infrastructures. 



Workshop Homepage 

http : / / WWW . vsb . cs . uni-f rankf urt . de/misc/QoSDOS/ 

J. Malenfant, S. Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 178- |19<J1 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 



1 Organizers 



Christian Becker 

FB Informatik 

Verteilte Systeme und Betriebssysteme 
Robert-Mayer-Str. 11-15 
60325 Frankfurt am Main 
Germany 

becker@ vsb . informatik .uni-frankfurt . de 



10 Moulton (6/3d) 
Cambridge, MA 02138 
USA 

jzinky@bbn.com 



John Zinky 

BBN Technologies 
Part of Verizon 



Quality of Service in Distributed Object Systems 179 



2 Workshop Objective 

Distributed Object middleware has emerged to solve the problems of distributed 
resources and heterogeneity in operating systems and languages. This middle- 
ware makes programming distributed applications easier. The programmer only 
has to deal with one set of standard interfaces which hide platform specific de- 
pendencies. The middleware’s runtime uses standard protocols and formats so 
that subsystems created by different programmers with different tools can have 
the resulting systems interoperate. Finally middleware provides a high-level ab- 
straction, so less new code has to be written and old code can be reused. 

Several middleware standards have emerged. Microsoft’s DCOM is a dis- 
tributed version of the COM application interface and is used to connect Micro- 
soft-based application together. OMG’s CORBA is a standards based middle- 
ware that addresses the heterogeneity issue. Dozens of CORBA implementations 
exist for many different languages and operating systems. Also, commercial and 
free-ware version of CORBA exist. Sun’s Java RMI uses the Java virtual ma- 
chine for it’s interoperability. Finally, web based object systems, such as SOAP, 
are emerging. Each of these Distributed object systems have their own niche and 
will co-exist for the immediate future. 



pjp Tclncl ^ 



rcp/ip 



X.25 : 



/Ethernet 



New Types of Applications were 
added without the need to understand 
anything about networks beyond the 
Sockets API 



New Networking Technol<»yies were 
added witliout the need to understand 
“anything about applications beyond 
their use of TCP/IP 



Fig. 1. The Simple Abstraction of TCP/IP Interfaces Allowed Networks and 
Applications to Evolve Independently 



While the heterogeneity problem has been addressed by middleware strate- 
gies, wide-area (WAN) distributed applications are still hard to build and main- 
tain. One of the problems is handling the high variability in the underlying 
components. First, WAN-based resources are more dynamic, unpredictable and 
unreliable. Application programmers are not used to writing code where an ob- 
ject can disappear between calls or may take an arbitrary amount of time to 
complete a call. Second, WAN-based applications have a wider range of end- 




180 Christian Becker and John Zincky 



users, each with different QoS requirements. The programmer is burdened with 
handling a wide range of usage patterns and requirements, which is hard to meet 
with just one implementation. Third, many resource allocation decisions can not 
be made until run time. Control of resources is an administrative matter in the 
user’s environment and can’t be successfully managed exclusively by the pro- 
grammer. Finally, many algorithms exist for accomplishing the same task, but 
which use different mixes of resources. Programmers are forced to use a general 
algorithm that works just adequately over a wide range of situations, instead of 
a custom algorithm that works well, but for a limit situation. 



Fig. 2. Applications and Networks can be Implemented More Efficiently, If More 
Information is Exchanged Across the Interface Boundary 

Some lessons can be learned from the successful deployment of the Internet. 
Dave Clark from MIT (circa 1996) has an explanation for why TCP/IP was so 
successful. His claim is that the socket-layer abstraction and the TCP/IP proto- 
col stack allowed networks and applications to grow independently (Figure [T|). 
New types of applications were added to the Internet without having to change 
the networking infrastructure. For example, the World Wide Web was a com- 
pletely unanticipated application which was built on top of TCP. The network 
also evolved without changing the applications. For example, the networking 
communities introduced new technologies, such frame relay and ATM, without 
changing any upper-layer protocols. Distributed object middleware has a similar 
role of allowing applications to evolve independently from the underlying system 
mechanisms. 

But the best-effort model for network communications does not work in all 
situations. Also, the guaranteed resource model of the phone-networks is too rigid 
for most computer-based applications. In hindsight, a spectrum of communi- 
cation services is needed. Applications and networks could be implemented more 
efficiently, if more information were available between them (Figure [2|). Thus, 
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Quality of Service (QoS) has became the language for moving additional infor- 
mation between applications and networks. QoS API’s defines how each should 
behave. Applications, such as video conferencing, need QoS guarantees from the 
network. Also, the network needs restrictions on the traffic patterns generated 
by the applications. Research in QoS has widened the TCP/IP choke point to 
include exchanging QoS information. What was once a simple interface has ex- 
ploded into a myriad of partial solutions which are still in flux after almost ten 
years. Because of their complexity and volatility, these network-based QoS in- 
terfaces need be hidden from the application developer. A similar situation is 
happening in operating systems and database research, which are also adding 
the notions of QoS to help manage CPU and storage resources. 
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Fig. 3. Distributed Object Systems with QoS Extensions is a New Abstraction 
Layer on which to Build Distributed Applications 



From the application’s prospective, the key to managing QoS is making trade- 
offs among resources. For example, knowing only about network resources is not 
enough information to decide whether a transfer should be compressed or not. 
Compression uses more CPU and memory resources in order to reduce consump- 
tion of network resources. The socket abstraction presented by the TCP/IP layer 
has no notion for CPU and memory resources, hence it is not powerful enough to 
manage QoS at the application layer. Distributed objects is the first abstraction 
layer that unifies CPU, storage and communications resources (Figure E]). The 
object’s state uses storage resources; the object’s methods use CPU resources; 
and the client/objects interactions use communications resources. 

Classic distributed object middleware tries to hide the underlying infrastruc- 
ture from the application developer in the same way that TCP/IP hides the 
network infrastructure from the socket-layer. Like TCP, the black-box approach 
is not an adequate API to develop adaptive applications, so distributed object 
middleware must be extended to manage QoS. But unlike TCP/IP, distributed 
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objects can unify the tradeoffs between the basic resources. Distributed object 
middleware with QoS extensions will be the new choke-point on which to develop 
distributed applications. This middleware will allow applications to develop in- 
dependently of the new QoS mechanisms being created to manage resources. 

3 Classification of QoS Middleware 

Although adding QoS to distributed object middleware is necessary, the state of 
the art is still at the experimental stage. Currently, many different schemes have 
be proposed and implemented as different groups have addressed QoS issues in 
their distributed object systems. This workshop looked at participant’s existing 
distributed object systems and tried to dissect them to see how they addressed 
QoS issues. The hope was to come up with a list of questions that can differentiate 
and categorize the different QoS approaches. The following questions were refined 
as part of the workshop: 
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Fig. 4. QoS Properties are at the Boundary Between the Client and Object 



What Kind of QoS Is Being Handled? 

Traditionally in the networking community, QoS has been associated with meet- 
ing guaranteed performance requirements for multi-media applications. Recently 
in the DARPA Quorum program and QuOIN project, the notion of QoS has 
been extended to include other system properties, such as real-time, dependabil- 
ity, security, and resource management. In addition, the notion of QoS has been 
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extended to be ” end-to-end” which goes beyond just the network to include the 
hosts and storage resources. Research has focused on managing only one kind of 
QoS at time, such as a real-time ORB or dependable ORB. Future research will 
attempt to combine multiple QoS properties, such as a secure real-time ORB. 
But sometimes the QoS properties conflict, which forces trade-offs between QoS 
properties. For example, overhead of security operations may preclude meeting 
real-time deadlines. Each distributed object system deals with a specific set of 
QoS properties, such as the TAO from Washington University at Saint Louis 
concentrates on real-time properties. 

Who Is Responsible for the QoS? 

Client and objects do not have QoS properties themselves, but the interaction 
between them does. When clients and objects are in the same process on the 
same host, QoS between them is well controlled and basically can be considered 
’’infinitely good”. But when a network connection separates the client from the 
object, QoS becomes an issue (Figure|4]). Current middleware, such as CORBA, 
does not manage network resources. This works fine as long as network resources 
are not the bottleneck, such as when using a high-speed LAN. But, when a 
resource is scarce, something has to be responsible for managing it. The burden 
can fall on the client, for example a smart browser accessing a web page. The 
burden can fall on the object, such as a load balancing server. Finally, the burden 
can fall on an intermediary, such as a QoS gateway or firewall. Each distributed 
object system offers mechanisms for supporting clients, objects or intermediaries. 
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Fig. 5. Current ORBS must be Extended to Handle QoS Interfaces and Control 
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Where Does QoS Adaptability Occur? 



Mechanisms for managing QoS fall into distinct layers (Figure E|. Underlying 
resources could manage QoS for themselves. But the QoS abstractions are at 
the resource-level and are hard for the application developer to use directly. 
The ORB can be specialized to manage a specific type of QoS. The QoS API 
is defined by the ORB and cannot be changed by the application developer. 
A wrapper-layer can be added above the ORB to add QoS support which the 
application developer can manipulate. Also, QoS services can be implemented 
as an overseer function in-between the client and object. Each distributed object 
system modifies layers in order to support QoS. 




Fig. 6. QoS Management has Different Roles 



What Roles Are Supported? 



Applications are not developed by a single programmer. Programming tasks 
are divided between roles which perform a specific kind of development (Figure 
E). Application developers want to create an application at the highest level 
possible. Application developers can be further divided in object developers who 
create a library of general purpose objects and client developers who hook the 
general objects together to make a specific applications. At the other end of the 
spectrum, mechanism developer are adding QoS management techniques into 
the underlying system. The QoS developer is a new role for creating libraries of 
adaptive schemes, which can be used by the object designer to create adaptive 
objects. These roles need radically different skill sets. Each distributed object 
system supports one or more of these roles. 
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In What Time Horizons Does Adaptability Occur? 

The object life-cycle has many time epochs in which adaptability can occur. 
At compile time, the marshaling is fixed and efficient stubs can be generated. 
At configuration time the application can be installed on the best servers. At 
connection time the type of adaptability can be bound. Finally at invocation 
time, the call can be routed to the best server. Each distributed object system 
supports adaptation for a specific set of time horizons 



How Is QoS Adaptability Reused? 

The most important service a distributed object system can support is reuse of 
adaptive mechanisms. These mechanisms can be hardwired into an underlying 
service, such as the RSVP protocol. Others can be in reusable libraries or tem- 
plates. Or the adaption can be supported by code-generators or compilers. Each 
distributed object system offer mechanisms for roles that can create adaptive 
mechanisms which can be reused. 

4 Summary of Contributions 

The organizer were delighted by the responses to the call for papers. The quantity 
and quality of the submissions exceeded our expectations. The review process 
selected papers not only according to their technical quality but also with respect 
to their potential to foster discussion. The contributions were classified along the 
end-to-end provisioning of Quality of Service in distributed object systems. The 
intention was to group the presentations according to their responsibility for QoS 
provisioning and to ensure that each presentation focussed on a distinct topic. 
A summary of each session appears below. 

4.1 QoS Support iu aud below ORBs 

The theme of this session was the provisioning of QoS below ORBs, i.e., operating 
system and network-related QoS provisioning. We thought that an emphasis 
should be given to the impact of ORBs residing on QoS enabled platforms, hence 
the second topic in this session dealt with the integration of QoS mechanisms in 
ORBs. In total, four papers were presented in this session. 

Two of the papers in this session dealt with the structure of communication 
in middleware architectures. Both approaches use generators to configure the 
protocols according the required QoS provisioning. Though one approach ex- 
plicitly follows the principles of Aspect Oriented Programming (AMIDST [T]) 
the other approach (Jung and Biersack |3]) could be classified in these terms as 
well. A common conclusion holds that relying on TCP/IP - as most middleware 
architectures do - is not appropriate for QoS provisioning. Configuring the mid- 
dleware is done in each case through generators. While the AOP-based approach 
uses information from the application-centered QoS requirements to configure 
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appropriate transport services in the ORB, the non-AOP approach allows cus- 
tomizable protocols through use of a generator. However, specifying QoS in the 
latter is still an open issue. Both address the separation of concerns with respect 
to QoS and application logic. 

The other two papers addressed QoS from a more platform-oriented perspec- 
tive. The design of a QoS-aware operating system kernel (Off-|— I- m and the 
integration of active networks in a CORBA-environment (IST-FAIN m show 
the connection of the protocol-oriented approaches to the underlying platform. 
The presented operating system kernel exposes QoS-related entities to applica- 
tion developers. A discovery protocol allows exploration of available resources. 
The kernel itself allows remote access to network related entities and their al- 
location. This work aims at the improvement of underlying platforms for the 
QoS-aware middleware above. In contrast, the integration of active networks 
and distributed processing environments requires an end-to-end view. Both the 
connection between application objects and their QoS requirements, and the QoS 
provisioning on the network are done through a modified bind process between 
client and server. The bind process can access the underlying active network 
through distinct abstractions, e.g., router-access interfaces. The communication 
protocols in the ORB can then rely on the active network’s QoS support. 

4.2 QoS Specification 

Though the majority of presentations were concerned with QoS frameworks 
based on object-oriented middleware, we selected two submissions related to 
the specification of QoS requirements from an application designer’s point of 
view. We viewed this as an ideal supplement to the QoS frameworks session 
since most QoS frameworks provide specifications for QoS issues as well. 

The specification-related contributions cover two areas of QoS specifications. 
The first area-involves the specification of the QoS requirements for multimedia 
applications in the OMODIS system j^. In order to allow Lecture-on-Demand 
(LoD) applications, the specification of desired application-specific QoS require- 
ments of data stored in a multimedia database, hierarchical contracts are intro- 
duced. QoS contracts model the user requirements in a multimedia presentation. 
Hierarchies offer convenience for complex presentations. They allow the speci- 
fication of global QoS requirements, which can be refined for distinct parts of 
the presentation. The proposed contract hierarchies allow negotiation of a com- 
plete multimedia presentation. Adaptation can be established in a fine granular 
manner, since only violated sub-contracts have to be renegotiated. 

The deployment of QoS dependent applications in the telecommunications 
domain is the focus of the EURESCOM Project 924 0. QoS requirements exist 
between components and are known up front. Though this restriction seems to 
ease the solution, the contribution motivates the lack of deployment support 
of current middleware systems as well as the need for QoS awareness in such 
services. The QoS aspects of concern are object locations, resource assignments, 
duplication and migration of objects. The proposed specification framework con- 
sists of UML specifications for the functional aspects and a distinct language for 
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the QoS constraints. These specifications are woven into an XML specification 
that is used to generate an installation map, scripts for the application setup 
and runtime constraints. 

Both specification contributions illustrate the necessity of complex specifi- 
cations when real-world requirements are addressed. Even the sole addressing 
of multimedia presentations requires much more support from QoS specification 
than the “classic” bandwidth and throughput issues, which are mostly concerned 
with a distinct channel between client and service. 

4.3 QoS Frameworks above the ORB 

This session - with six presented contributions and even more submitted - rep- 
resented the major part of the workshop. Although QoS frameworks typically 
consist of specifications as well as embedded QoS mechanisms below the ORB, 
this session was dedicated to contributors describing their work in a larger con- 
text. 

The contributions can be classified as generic multi-category QoS frameworks 
and single category multimedia supporting frameworks. While one of the mul- 
timedia approaches (Djinn [5j) uses middleware only to control the interactions 
in a multimedia system and provide a two layer abstraction of the components 
involved, the other approaches all rely on modified ORBs. 

The modified ORBs all address the necessity of integrating customized pro- 
tocols. As mentioned in the “QoS below and in the ORB” session currently 
middleware relies mostly on TCP/IP, which is not sufficient for most QoS re- 
quirements. Hence, each approach provides distinct dispositions for the integra- 
tion of application-specific transport protocols. 

One approach uses QML - a QoS specification language from HP Labs, Palo 
Alto - to describe the QoS requirements (Dittrich, Solarski [^). The QML spec- 
ification is mapped to an augmented ORB, which provides means for protocol 
integration and an extended binding interface through which application objects 
can access the appropriate QoS transport. Reliability, scalability and availability 
are the supported QoS categories. 

The specification of QoS requirements by nested contracts from the QoS 
specification session is mapped to an augmented ORB in the MULTE project 
m- This ORB provides a layered architecture consisting of application spe- 
cific mechanisms, QoS binding related logic, and QoS mediation to underlying 
resources. The three layers offer a wide variety of different QoS implementa- 
tions with flexible signaling mechanisms. It seems likely that this architecture is 
suitable for other specification mappings as well. 

One of the generic approaches introduces a QoS meta model for the specifica- 
tion of QoS contracts using XML and the Meta Object Facility (MOF) (Daniel, 
Traverson, Vignes 0). The QoS contracts, specified in a distinct language (QoS 
Description Language (QDL), are mapped to QDL. The underlying QoS manage- 
ment framework is responsible for enforcement of the QoS contracts (guaranty, 
observation, negotiation and composition). The authors claim to provide QoS 
management independently of the application domain. 
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The last two contributions present an AOP-based approach. However, both 
differ in the choice of aspect languages. While MAQS [l2j uses an extension 
to OMG-IDL in order to describe the QoS and application specific interfaces, 
QuO m offers a variety of specialized description languages. Both approaches 
offer the integration of application-specific QoS mechanisms at multiple layers 
in and around the ORB. The AOP-based approach separates the QoS related 
behavior from the application behavior. Since programmers are familiar with 
IDL-compilers for building applications using middleware platforms, enhancing 
the IDL-compiler or an additional phase of IDL-compilation is a good solution 
for weaving of QoS aspects. 



4.4 QoS Enabled Applications 

This session has been dedicated to QoS provisioning in object systems from an 
application developers view. We hoped for several examples of QoS integration in 
object systems. Unfortunately, there were some cancelations and thus only one 
participant presented in this session. DVECOM project m deals with end user 
QoS requirements in a distributed virtual environment for Computer Supported 
Collaborative Work (CSCW). The QoS characteristics of interest are related to 
synchronization and real-time aspects of service provisioning. 



5 Conclusions and Recommendations 

The most important conclusion is perhaps the most obvious, that QoS must 
concern more than the classical consideration of bandwidth, delay and jitter 
provisioning. QoS must concern security, dependability and other performance 
related aspects as well. 

The integration of QoS mechanisms in middleware infrastructures is ad- 
dressed with similar integration points and QoS provisioning responsibilities. 
The lack of standardization is quite evident in that area, since all presented 
approaches state the same needs and offer similar solutions. 

In contrast to the mechanism integration in the ORB, which is rather agreed 
upon, the specification of QoS requirements and the integration of QoS provi- 
sioning into the application are handled quite differently. The generic approaches 
featured aspect-oriented programming based on weaving of aspect languages. 
However, the degree of information factored out into the aspect languages dif- 
fers. As well, the specification of the non-AOP approaches differ greatly. The 
necessity to specify QoS parameters that reflect the state of the system with 
respect to a certain QoS characteristic is addressed quite differently among the 
presented architectures. Some solutions focus on the negotiation of QoS agree- 
ments and offer specifications tailored to this purpose, while others only represent 
the state and add an additional specification for negotiation. We view this area 
as an important field for further research. 

Middleware integrates QoS management from applications to the underlying 
platform. It is crucial to provide clear mappings between QoS specifications and 
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the corresponding behavior in order to establish the end-to-end provisioning of 
a QoS characteristic. However, the integration of QoS behavior in applications 
is handled differently by each approach. It is still unclear whether a generic 
framework can cover all domains of QoS management. The requirements on 
the underlying platform that arise from QoS provisioning by middleware, also 
warrants further study. 



6 Lessons Learned by the Organizers 

The workshop attracted a variety of researchers from the domain of QoS man- 
agement in distributed object systems. This enabled a selection of presentations 
not only driven by the quality of the submitted abstracts, but also governed by 
the workshop program. As a result the workshop covered not only the impact 
of QoS integration on middleware architectures but also adjacent areas, i.e., op- 
erating system, network, applications, and QoS specification. We consider this 
as an ideal base when discussing middleware. However, a typical presentation- 
questions-panel organization might not be the best to foster discussions among 
the participants. 

Although the variety of approaches made it difficult to cut down the program 
to even fewer presentations, this would have allowed more and deeper discussions. 
Nevertheless, bringing together researchers from all QoS related layers proved 
useful, since the exchange of requirements and experiences can be helpful. In 
order to allow this exchange happen, the workshop size should not grow beyond 
15 presentations. 

We believe the workshop meets a need that is not addressed by other work- 
shops, e.g. Middleware, IWQoS, Reflective Middleware. These venues are either 
too broad, e.g. covering all middleware or QoS aspects with a resulting high 
number of participants, or too specialized, e.g. Reflective Middleware. 
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Abstract. The aim of the First ECOOP Workshop on XML and Ob- 
ject Technology was to bring together researchers working in the object- 
oriented field to discuss how object-oriented technology can be exploited 
in data management solutions for XML M and which issues require 
new developments and further investigation. The workshop consisted of 
a number of presentations of reviewed papers and of discussions on var- 
ious aspects related to the main topic of the workshop. 



1 Introduction 

The main motivations behind the First Workshop on XML and Object Tech- 
nology are related to the explosive growth of the World Wide Web. Indeed, 
companies and organizations are today massively using the Web as the main 
information distribution means both at the internal and external level. Such a 
widespread use of the Web has pushed the rapid development of suitable stan- 
dards for information representation. XML (extensible Markup Language) [H] 
is currently the most relevant standardization effort in the area of data ex- 
change through markup languages. The main advantages of XML, compared 
with HTML, are the possibility of defining tags, nested document structures, 
and document types (called DTDs -Document Type Definitions-), describing the 
structure of XML documents. Because of the relevance of XML in the Web en- 
vironment, many research efforts are now concentrated in investigating various 
issues related to the use of XML as a data representation language. One of the 
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relevant characteristics of XML is that it has many similarities with object- 
oriented data models and languages. However, whereas the object-oriented tech- 
nology has reached a great level of maturity, XML is still in its infancy. Thus, the 
main goal of the First Workshop on XML and Object Technology was to discuss 
how object-oriented technology can be exploited in data management solutions 
for XML and which issues require new developments and further investigation. 
In particular, our aim was that of exploring whether and how the expertise and 
the results (both at the theoretical and at the technological level) which have 
been reached in the object-oriented field can be applied to XML. 

Submissions of papers describing various aspects related to the topic of the 
workshop were invited, including but not limited to the following aspects of the 
development of an XML-based system: 

— Data models and database design 

— Query languages 

— Query processing and optimization 

— Access methods and data structures 

— Access control and security 

— Data mining and knowledge discovery 

— Database performance and benchmarks 

~ User and application interfaces 

— Experience using XML and objects 

— XML standards. 

The program committee of the workshop was composed by seventeen experts 
in various fields of both object-oriented and XML technology. Some of them had 
a more theoretical background whereas others were more focused on architec- 
tural and implementative aspects. The program committee members and their 
affiliations are listed below: 

— Nabil R. Adam, Rutgers University, USA 

— Paolo Atzeni, University of Rome, Italy 

— Elisa Bertino, University of Milano, Italy 

— Silvana Castano, University of Milano, Italy 

— Mary Fernandez, AT&T Labs, USA 

— Daniela Florescu, Inria, France 

— Piero Fraternali, Politechnic of Milano, Italy 

— Zack Ives, University of Washington, USA 

— Sanjay Kumar Madria, Purdue University, USA 

— M. Tamer Ozsu, University of Alberta, Canada 

~ Yannis Papakonstantinou, University of California San Diego, USA 

— Jerome Simeon, Bell Labs, USA 

— Dan Sudu, AT&T Labs, USA 

— Athena Vakali, Aristotle University of Thessaloniki, Greece 

— Masatoshi Yoshikawa, Nara Institute of Science and Technology, Japan 

— Philip Wadler, Bell Labs, Lucent Technologies, USA 

— Roberto Zicari, Johann Wolfgang Goethe-Universitaet, Germany. 
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All submitted papers were thoroughly reviewed by the program committee 
members and by a small number of external reviewers. The names and the 
affiliations of external referees are listed below: 

— Michele Melchiori, University of Brescia, Italy 

— Marco Mesiti, University of Genova, Italy 

— Takeshi Sannomiya, Nara Institute of Science and Technology, Japan 

— Yu Suzuki, Nara Institute of Science and Technology, Japan. 

Based on the reviews, eight papers were selected for presentation at the 
workshop. Accepted papers have been collected into informal proceedings that 
were distributed to each participant at the beginning of the workshop. They are 
also available at 

http : //www. disi .unige . it/ conf erences/xot2000/prograjn.html. 

The accepted papers were grouped into three main categories: XML under 
Distributed Environments, XML Engineering, and 00 Models and XML. To 
each group, a session of the workshop has been devoted. Each accepted paper 
has been presented by one of the authors. Thirty minutes have been assigned to 
each paper: twenty minutes for the presentation and ten minutes for questions. 
The workshop ended with a final discussion in which the contributions of the 
workshop had been summarized and future research directions were discussed. 

Twenty people attended the workshop coming from more than nine different 
countries. The atmosphere of the workshop was rather informal and this has 
greatly facilitated discussions and exchange of opinions among participants. The 
list of participants can be found at the end of this report. Each presentation 
was followed by many questions and the final discussion was very lively and 
interesting. 

The remainder of this report is organized as follows. Section is devoted to 
the session on XML under Distributed Environment. Section[^discusses the main 
contributions of the session on XML Engineering, whereas Section [4| illustrates 
the session on 00 Models and XML. Section [^presents the main issues addressed 
by the final discussion. Section presents some useful references related to the 
topic of the workshop, whereas Section |3 concludes the report. 

2 XML under Distributed Environments 

The starting session of the workshop was devoted to XML under Distributed 
Environments. The aim of this session was to investigate various aspects of 
the use of XML in distributed environments, with particular focus on the Web 
environment. Two papers were presented in this session focusing on two different 
aspects of the problem. 

The first paper, presented by Claude Pasquier, focused on editing environ- 
ments for XML documents and illustrated a prototype of a distributed editing 
environment over the Internet |S]. One of the distinguished features of XML is 
the separation between the information itself and the way it is displayed. Such 
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separation allows the elaboration of specialized interfaces to visualize or mod- 
ify XML data. A lot of efforts were made to develop tools and standards to 
display and modify XML. For instance, the World Wide Web Consortium had 
proposed several standards to visualize XML documents [isfiel and to transform 
them m- However, these standards are mainly focused on data visualization, 
whereas little work has been done to address the problem of data modification. 
Such problem is crucial when dealing for instance with e-commerce applications 
over the Internet. For example, a vendor may want to update via Internet (using 
a laptop or a mobile phone) the database of its company with new information 
concerning visited clients. 

The prototype system that was presented in the first paper |S] of the ses- 
sion on XML under Distributed Environments represents a step towards the 
development of a distributed editing environment for XML data manipulation. 
The prototype is based on a software development environment called Centaur 
|3]. The key point of the proposed system is the way it handles user interac- 
tions. Selections and modifications made by users are not directly reflected on 
the concrete view of the document. Rather they are serialized and transmitted 
to a server which applies them to the view. Correspondence between the vari- 
ous versions of XML documents are expressed through the declarative language 
XPPML, an extension of the pretty-printing meta language PPML defined in 
the Centaur system. With this organization, the amount of software needed at 
the client site is kept minimum and consists of a communication layer, that sends 
and receives messages over the network, and a layout engine. All the other com- 
ponents are at the server site and thus the proposed architecture is particularly 
well-suited for situations where clients have sparse resources. 

The first paper received a lot of attention and several questions were raised 
during the discussion following the presentation. The architectural choices con- 
cerning the proposed tool were discussed and the restructuring approach was 
further motivated. It was also debated the choice of performing transformation 
at the server side, instead that at the client side. Under this approach, all the 
intelligence can be concentrated at the server-side and the size of the clients, 
that are only concerned with the display of the structures, can be minimized. 
This approach is motivated by the fact that often clients do not have a sufficient 
knowledge of the whole document structure to be able to perform the trans- 
formation. Finally, the differences between the proposed restructuring approach 
and restructuring capabilities supported by existing XML query languages were 
also debated. 

Additional information concerning the work presented in this paper can be 
found at the home page of the speaker (http://www-sop.inria.fr/lemme/ 
Claude . Pasquier/index-en. html) and at the home page of the project un- 
der which the work has been developed (http://www-sop.inria.fr/lemme/ 
main-e . html). 

The second paper of the session, presented by Emmanuel Nauer and Rim Al 
Hulou, was a position paper | 7 ] that focused on the role that can be played by 
XML for reasoning and problem solving on textual data. Examples of problems 
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posed on textual data are the merging of different textual sources, guided navi- 
gation on the Web, text mining and so on. Information retrieval, both content- 
based or keyword-based, plays a crucial role in solving the above mentioned 
problems. However, content-based information retrieval is not an easy task since 
the information accessible through the Web is distributed among many sources 
and stored with many heterogeneous representations and formats. Most of the 
data available on the web are semi-structured, that is, they are irregular data that 
do not conform to a global fixed schema jl]. The authors of the paper claimed 
that, to overcome the difficulties of content-based information retrieval, a good 
starting point is finding a model to represent semi-structured data. The paper 
thus proposed a knowledge representation formalism for this purpose, which is 
based on semi-structured objects and polythetic concepts. The use of such for- 
malism is greatly facilitated if a unified format for describing data selected from 
different sources is adopted. In the paper the authors proposed the usage of 
XML as a bridge between semi-structured data and the object formalism for 
their representation, and showed the benefit of XML usage. 

Questions regarding the second paper concerned the proposed knowledge 
representation formalism and the relationships among such formalism, object- 
oriented concepts, and the XML-based representation. The advantage of using 
an XML-based approach with respect to other possible alternatives has also been 
discussed. 

3 XML Engineering 

The goal of the session on XML Engineering was to understand which role XML 
can play in all the stages of software and hardware products development and 
which are the benefits arising from the use of XML in this context. This area 
seems to be one of the main area of application of XML and most of the papers 
submitted to the workshop addressed issues related to this field. Three papers 
were presented in this session, which illustrated the use of XML at various stages 
of product development. 

The first paper of this session, presented by Yassin Aziz Rekik, addressed the 
problem of document development |S]. This process has many similarities with 
the development of software products and can be organized into three major 
steps: modeling, authoring, and processing. The paper proposed a component- 
based approach for facilitating reuse during document production, specifically 
conceived for XML documents. The main features of this approach are the pos- 
sibility of defining generic document components which can be reused for several 
different XML documents. 

The paper generated a lively discussion during which a lot of questions have 
been raised. In particular, the notion of flexible structure, introduced by the 
paper, was better clarified, as well as the ability to use the proposed approach 
at different development levels. 

The second paper of the session on XML Engineering, presented by Daniel 
Deveaux, was devoted to the role of XML in software project management [3- 
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Most of the applications of XML in such area can be grouped into three main 
categories: documentation management, data interchange, and lightweight data 
storage. In this paper, the authors had proposed an alternative use of XML in 
the software development process. The use of XML can greatly contribute to 
solve interoperability problems arising in the software development process be- 
cause of the use of several heterogeneous software tools each one characterized 
by a different internal model. The idea proposed in the paper is to use XML 
to provide the technical infrastructure to enable the integrated management of 
all core software development information. Such idea builds on the concept of 
design for testability, previously introduced by the authors, which based on a 
self-documented and self-testable class model. One of the main contributions of 
the paper was the development of a DTD for a master document type capturing 
all the information relevant for a particular class, such as for instance docu- 
mentations, contracts, and tests. The paper also discussed an architecture built 
around the DTD prototype. 

During the second talk, a demonstration of the proposed approach was pre- 
sented, that clarified the proposed usage of XML for testability. After the work- 
shop, the work has been extended by developing a Java-to-Java generic tool that 
uses two levels of DTD, one covering the full syntax of Java with javadoc com- 
ments, and one extending that presented in the paper with the ability to manage 
in-methods structures. The first application of the proposed approach is a Java 
pretty-printer and the authors are currently working on a contracts preprocessor 
and a mutation generator. 

Additional information concerning the work presented in this paper can be 
found at the home page of the speaker (http://www-homes.iu-vannes.fr/ 
~deveaux/) and, starting from October 2000, at the XML4SE {XML for Soft- 
ware Engineering) site (http://www.iro.umontreal.ca/labs/gelo/xml4se). 

The last paper of the session on XML Engineering, presented by Matt Hol- 
gate, dealt with the design of large systems-on-chip |B]. Such systems could be 
very complex and this has led to an increased interest in hardware re-usable 
components. Such components are then pieced-together with application spe- 
cific logic to produce entire systems on a single chip. However, this approach has 
several problems and one of the most important is the lack of a standard descrip- 
tion language for components. Typical system-on-chip designs usually consist of 
hundreds or thousands of source files containing both actual hardware designs 
and their meta-data, which are typically combined in an ad hoc manner. To 
cope with this heterogeneity, the authors proposed the usage of XML as a sys- 
tem description language capable of encapsulating and documenting all pieces of 
data and meta-data related to system-on-chip designs in a unified manner. The 
paper also presented chipmake, a tool which takes as input an XML document 
describing a chip design, and automates the building and evaluation process. 
The paper includes an example of usage of chipmake on a small example circuit. 

The presentation of this paper, proposing a real application of XML to an 
engineering problem, resulted to be quite interesting for people attending the 
workshop. The discussion following the presentation pointed out what are the 
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main advantages in using an XML-based approach with respect to other possible 
solutions. 

Additional information concerning chipmake can be found at 
http ; //www. dcs . gla. ac .uk/~matt/research/chipmake/ and from the home 
pages of the authors (http://www.dcs.gla.ac.uk/~matt/ and 
http : //www. dcs . gla. ac .uk/~ Jonathan/). 



4 OO Models and XML 

The last session of the workshop had the goal of exploring the relationships be- 
tween object models and the XML language under different prospectives. Three 
papers were presented in this session. 

The first paper, presented by Athena Vakali, exploited the use of an object- 
based approach for XML data storage m- The paper proposed an object-based 
XML data representation model for the effective placement of XML data. The 
authors proposed a two levels scheme: the external level supports the notion of 
browsing graph for the navigation among XML documents, whereas the internal 
level is based on a tree-like structure for the representation of the XML document 
itself. The main contribution of the paper is that it exploits the object data 
model to consider XML data dependencies, access frequencies, and constraints. 
The paper presented a simulation model developed to evaluate different XML 
data placement strategies and the impacts of the proposed model in the overall 
storage process. The paper considered three popular data placement policies: 
Organ-pipe, Camel, and Simulated Annealing and experiments were shown for 
different synthetic workloads of XML data sets. Simulated annealing has been 
proven to be the most beneficial placement policy with significant improvement 
rates in both seek and service times. 

Since the first paper of the last session dealt with a typical data management 
problem and people attending the workshop did not have a database background, 
the discussion following the presentation clarified some basic aspects of the stor- 
age problem, pointing out the differences between storage of XML documents 
and storage of objects, in an object-oriented context. 

The second paper of the session on OO Models and XML, presented by 
Alessandro Longheu, dealt with the use of XML and object models in the frame- 
work of manufacturing processes [1] . Modern manufacturing processes are highly 
structured and automated. Thus, their management requires a logical production 
model which may be quite complex and which must be periodically re-engineered 
to keep it updated with new needs and requirements. The paper illustrated 
the use of XML to describe the re-engineered object-oriented STMicrolectronics 
manufacturing model, used for production flow definition and management. The 
first part of the paper had been devoted to the presentation of the main features 
of the object-oriented model, such as constitutional and aggregational hierar- 
chies, process, product, and operation, and the flexible inheritance mechanism 
between process and product. Then, the paper illustrated the XML represen- 
tation of each class and instance, showing in details how each feature of the 
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object-oriented model can be represented through XML. Finally, the paper il- 
lustrated how the XML representation of the model is used, together with a Java 
applet, to manage production flow inside the STMicrolectronics Intranet. 

The second presentation explicitly pointed out how a manufacturing process 
can be modeled by using XML. All the modeling steps were clarified during the 
presentation and the motivation concerning the choice of XML in modeling such 
processes was further debated during the discussion. 

The last paper of the session on 00 Models, presented by Michael Baum- 
hackl, dealt with the problem of integrating heterogeneous biomolecular data- 
bases [2]. Advances in DNA sequencing have lead to an overwhelming amount 
of biochemical and biomolecular databases which usually have been created to 
manage data collected during a particular project. As a consequence, data are 
stored and organized into a variety of heterogeneous formats. The paper pre- 
sented the result obtained in the context of the Data Alive Project carried out 
by the Scientific Database and Visualization Group of the European Media Lab- 
oratory. The paper discussed several approaches to the integration of databases 
that offer XML and/or distributed object interfaces to their data, pointing out 
the differences of the various approaches and showing how they should comple- 
ment each other. 

The discussion following the third presentation clarified some specific archi- 
tectural details concerning the technology used in the project and introduced 
during the presentation. 

Additional information concerning the Data Alive project can be found at 
http ; / / WWW . villa-bosch . de/eml/english/ research/ data/ data . html. 

5 Final Discussion 

The final discussion was organized in two parts. During the first part, Barbara 
Catania and Athena Vakali summarized the main results contained by the pre- 
sented papers. 

The main conclusions concerning the first session (XML under Distributed 
Environments) can be summarized as follows. XML can be successfully used as 
an interchange format between data and representation formalisms [?]• In partic- 
ular, the idea presented in [2] of using XML as a bridge between semistructured 
formalisms and more structured ones seemed quite promising. On the other hand, 
there is the need of using XML in a distributed environment and, to this pur- 
pose, the development of distributed editing environments is quite important. 
The discussion concerning the second session, dealing with XML Engineering, 
came up with the conclusion that there is the need of techniques for designing 
XML documents (engineering for XML documents) and, to this purpose, the 
modular approach seems quite promising. On the other hand, there is also the 
need of using XML as a support in object-oriented design of software and hard- 
ware components (engineering based on XML documents). Finally, the third ses- 
sion (00 Models and XML) pointed out that, besides modeling and integration 
purposes, several issues have to be investigated concerning XML data manage- 
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ment. To this purpose, the general opinion was that object-oriented technology 
can be successfully exploited in providing data management solutions for XML 
documents. 

From the discussion, it resulted that XML has indeed a proper life with 
respect to object-orientation, even if there are several relationships between these 
two technologies. In particular, the most important usage of XML up to now 
seems to be the ability to serialize instances of object-oriented applications for 
data exchange. This means that, given an application based on an object-oriented 
logic, XML can be seen as the right choice for providing a more external view of 
such application, useful for data specification, integration, and exchange. Papers 
mmr\ proposed contributions concerning this aspect. On the other hand, 
with difference to the object-oriented technology, XML does not support a real 
data model. However, the characteristics of XML documents resemble those of 
semi-structured documents m- Therefore, new approaches and techniques have 
to be exploited in order to support at least two main aspects: 

— XML document design [819] 

— XML data management m- 

To this purpose, object-oriented technology has to be exploited and extended to 
correctly support the modeling and the management of XML-based data. 

Among the previous issues, the last one concerning XML data management 
problems was only partially covered by the workshop. However, people attending 
the workshop declared their interest in this topic. For this reason, the second 
part of the discussion was devoted to an introduction to XML data management 
issues for XML. The presentation, given by Barbara Catania and Athena Vakali, 
tried to point out what are the main data management problems for XML. Such 
problems have been classified as follows: 

— XML data representation 

— XML query languages 

— XML data access control 

— XML data storage and indexing. 

Concerning data representation, we pointed out that XML documents can be 
either seen as a set of documents or as an interchange format. This interpretation 
is supported by the fact that XML is not a data model and therefore we need 
to map XML-encoded information into a true data model in order to easily 
deal with it m- Some database management systems for XML support already 
existing in the market were also discussed, pointing out the main technological 
differences among them. People attending the workshop were quite interested in 
this discussion. Concerning XML query languages, the basic properties of such 
languages were pointed out. The ability of restructuring XML documents was 
also discussed and related to what was presented during the other sessions of the 
workshop. Concerning XML data access control problems, we pointed out that 
there is the need of a controlled dissemination of XML documents and thus there 
is also the need of identifying suitable access control policies for XML documents. 
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On the other hand, the definition of an XML library for the encoding of access 
control policies and authorizations could be quite useful. Finally, the need for 
representation models for XML data was pointed out. Such representations must 
then be used as an underlying formalism for defining caching, clustering, and 
indexing techniques, tailored to XML documents. 

The discussion concluded with the consideration that, even if several ap- 
proaches have already been proposed concerning XML data representation and 
querying, much work has still to be done in order to cope with security, storage, 
and indexing aspects. To this aim, we can get benefit from techniques defined 
by the object-oriented community, especially for what concern the management 
of semi-structured data. 



6 Pointers to Related Work 

In this section, we provide the reader with some pointers to web pages related 
to the topic of the workshop. An important point to start learning about XML 
is certainly the W3C consortium site at http ; / / www . w3c . org. Other important 
sites containing several useful information concerning XML are http ; / / www . xml- 
zone, com/ and http : //www. xmlephcint . com/. References to several books on 
XML can be found from these sites. For a good survey concerning XML and data 
management, we refer the reader to |13| . Information concerning XML and secu- 
rity can be found at the Christian Geuer Pollmann’s Web Page, http : //www . nue . 
et-inf . uni-siegen . de/~geuer-pollmann/ xml_security . html. Information 
concerning the application of new XML technology to the Software Engineering 
domain can be found at http://www.iro.umontreal.ca/labs/gelo/xml4se, 
where XML4SE stands for XML for Software Engineering. The goal of this site 
is to inform on academic and professional projects that are developed in this 
topic. 

As important events, related to XML and object technology, we recall the 
XML Days, that will take place in several European town. For further informa- 
tion, we refer the reader to http : / / www . Itt . de/ xml . html . Few other workshops 
concerning XML and Object Technology have already taken place. Among them, 
we recall the XML and Objects - OOPSLA99 Workshop, November, 1999, and 
the ACM SIGIR 2000 Workshop On XML and Information Retrieval, Athens, 
Greece, July, 2000. 



7 Conclusions 

The workshop contributions showed that XML technology can definitely take 
advantages from object technology. However, even if a considerable amount of 
work has already been done, much more work is needed to combine these two 
worlds. During the workshop, it has been also pointed out that this is an “hot” 
topic, on which several important research groups are currently working, all over 
the world. 
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We are quite happy of the results of the First ECOOP Workshop on XML and 
Object Technology. The number of submitted papers was higher than expected 
and the decision of keeping low the number of participants guaranteed a high 
interaction and an informal environment, in which discussion easily took place. 
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Abstract. This document describes the results of the two-day Workshop on 
Aspects and Dimensions of Concern at ECOOP 2000. The workshop produced 
the beginnings of a set of goals, requirements, and issues to be addressed by 
approaches to advanced separation of concerns. These goals and issues are 
encapsulated, in part, in a set of challenge problems that are intended to be 
solved by providers of advanced separation of concerns technologies. The 
challenge problems and requirements begin to define the boundaries of this 
problem domain and solution space, and they will help provide a basis for 
evaluating and comparing different solutions and solution approaches. 



1 Introduction 

The First Workshop on Aspects and Dimensions of Concern was held at ECOOP 
2000, following several previous workshops on Aspect-Oriented Programming, 
Subject-Oriented Programming, and Multi-Dimensional Separation of Concerns. 
Whereas the goals of previous workshops had been to introduce and begin to explore 
the new subdomain of advanced separation of concerns, this workshop’s purpose was 
instead to begin to define a set of concrete goals for, requirements on, and issues to be 
addressed by, approaches to advanced separation of concerns. The explicit 
representation of these goals, requirements, and issues represents the start of the 
transition of advanced separation of concerns from an infant subdiscipline to a 
coherent, mature research area. When completed, they will help to define the 
boundaries of the problem domain and solution space, and they will provide a basis 
for evaluation of, and comparison among, different solutions and solution approaches. 



* This workshop was funded in part by Xerox PARC and IBM Research. 

J. Malenfant, S. Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 203-240, 2000. 
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To accomplish the workshop goals, we brought together both practitioners and 
researchers who have experienced problems related to inadequate separation of 
concerns, and practitioners and researchers who have provided solution technologies 
or approaches that address these problems. It was our intention to establish a dialogue 
between these two groups, to reveal the needs of the former group and the capabilities 
of the latter, thus facilitating the identification of goals, requirements and issues for 
advanced separation of concerns. To achieve this, prospective participants were 
required to submit position papers describing either some problems they had 
encountered, or solutions they had developed, in the field of advanced separation of 
concerns. This resulted in more than 40 experienced researchers and developers 
participating in the workshop, and their position papers can be found on the workshop 
web site, http: //trese. cs.utwente.nl/Workshops/adc2000. 

As a highly interactive setting seemed most suitable, we allocated the larger 
amount of the two-day workshop to group work, only occasionally alternating it with 
invited talks from some of the experts in the field and authors who provided highly 
incisive, challenging problems. Seven heterogeneous groups were formed, joining 
problem providers with solution providers, and distributing co-authors or colleagues 
over as many groups as possible. This policy ensured that as wide a variety of 
submitted problems and solutions as possible were discussed in each group. Over the 
two days, the groups analyzed selected problems and evaluated some solutions by 
applying them to the problems. Each group presented both an interim report and their 
final results. The workshop concluded with a panel consisting of one representative 
per group, which proved to be a valuable source of general insights to the community. 

The rest of this document describes some of the results of this two-day workshop. 
Depending on the viewpoint adopted by a group — either the problem perspective or 
the solution perspective — the group work resulted in the following kinds of results: 

- Challense problems '. Challenge problems are software engineering scenarios that 
highlight one or more key problems and issues in advanced separation of concerns. 
The problem statement also describes any necessary requirements or constraints on 
solutions. Challenge problems, as their name suggests, are intended to serve as 
challenges to those researchers and developers in this subdomain who have 
produced, or who will produce, models of, or tools to support, software 
engineering using advanced separation of concerns. It is our hope that the 
producers of such models and technologies will propose solutions to the challenge 
problems using their models and technologies. As a result, we expect that some 
limitations or interesting features of existing models and technologies will be 
uncovered, prompting new research, and that the various solutions will be used as a 
basis for comparing and contrasting the relative strengths and weaknesses of 
different approaches. 

- Generalization of challense problems : Particular subsets of challenge problems 
suggest larger, abstract classes of problems. Such generalizations are particularly 
critical, as they help to identify and categorize key parts of the problem domain. 

- Requirements statements '. Some of the requirements on advanced separation of 
concerns approaches are already well defined; for example, an advanced separation 
of concerns approach must facilitate the encapsulation of multiple kinds of 
concerns, including those that cross-cut objects. Many requirements, however, are 
not well defined or widely accepted. Requirements statements highlight 
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requirements on approaches to advanced separation of concerns, and they are 
generally illustrated with examples. It is our intent that the producers of advanced 
separation of concerns models and technologies will indicate how their models and 
technologies address these requirements; if they do not, we hope that they will use 
the requirements to help them identify new areas for subsequent research. 

Each result is classified accordingly. 

The remainder of this document is organized as follows. Sections ^REI^ 
describe, respectively, the results produced by a particular workshop subgroup. 
Finally, Section^Jjresents some conclusions and future work. 

Clearly, a single, two-day workshop is not sufficient time to produce a complete 
set of requirements, issues, or challenge problems, or even to produce a representative 
set. The results reported in this document are preliminary. Subsequent efforts may 
determine that some of the results are incomplete, inadequate, mutually inconsistent, 
or erroneous. It is our intention for these results to be discussed, revised and 
expanded by the advanced separation of concerns community. Beyond all else, this 
document is intended to provide food for thought. 

1.1 Contributors 

The results described in this paper are due to — and in many cases, adapted from 
reports written by — the workshop participants and organizers: Mehmet Aksit, Jean 
Paul Arcangeli, Federico Bergenti, Lodewijk Bergmans, Andrew Black, Johan 
Brichau, Isabel Brito, Laurent Bussard, Lee Carver, Constantines Constantinides, 
Pascal Costanza, Krzysztof Czamecki, Lutz Dominick, Maja D’Hondt, Wolfgang De 
Meuter, Kris de Voider, Erik Ernst, Robert Filman, Eric Hilsdale, Mathias Jung, Pertti 
Kellomaki, Mik Kersten, Gregor Kiczales, Thomas Kiihne, Donal Lafferty, Cristina 
Videira Lopes, Mira Menzini, Tommi Mikkonen, Blay Mireille, Oscar Nierstrasz, 
Klaus Ostermann, J. Andres Diaz Pace, Renaud Pawlak, Elke Pulvermuller, Bert 
Robben, Martin Robillard, Andreas Speck, Erlend Stav, Patrick Steyaert, Peri Tarr, 
Tom Tourwe, Eddy Truyen, Bart Vanhaute, John Zinky. 



2 Safe Composition 

Group members: Laurent Bussard, Lee Carver, Erik Ernst, Mathias Jung, Martin 
Robillard, and Andreas Speck 

Issues: Semantically correct composition of aspects, concerns 
Categories: Challenge problems, requirements statements 

2.1 Problem Overview 

Different aspects or concerns should only be composed when the result of composing 
them is semantically meaningful. Two classes of conflicts may occur among 
concerns that are to be composed which, if present during composition, may affect the 
correctness of the composed result: 
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- Semantic mismatch conflicts : Semantic mismatch conflicts are ones in which the 
composition of two or more concerns produces semantically incorrect programs. 
The mismatches occur when composed concerns contain behaviors that interact in 
subtle (often multiple) ways, and the interactions are not addressed correctly in the 
composed program. 

We further divide the class of semantic mismatch conflicts into intentional and 
unintentional conflicts. Intentional conflicts are ones that are introduced 
deliberately by a developer — i.e., the developer designs two or more concerns or 
aspects to conflict (e.g., to be mutually exclusive). Unintentional conflicts, on the 
other hand, are ones that occur inadvertently, often due to non-obvious semantic 
interactions among the concerns or aspects. While these kinds of semantic 
mismatch conflicts look the same, we distinguish them because addressing them 
requires different kinds of support from advanced separation of concerns 
mechanisms. Intentional mismatches require a means for allowing developers to 
assert that a set of concerns or aspects is intended to conflict. Unintentional 
mismatches, on the other hand, require compositor and/or run-time detection 
capabilities, and they must be resolved, either automatically or manually (e.g., with 
“glue” aspects or mediators), to produce a correct composed program that contains 
all of the (originally conflicting) aspects. 

- Spurious conflicts '. As their name suggests, spurious conflicts are ones that are 
identified as conflicfs erroneously — i.e., the composed program would actually run 
correctly — due to the limitations of static or otherwise overly conservative type 
checking. Addressing spurious conflicts is difficult and may necessitate a choice 
between aspect reuse and static type checking, but it may be addressable with more 
powerful type analyses. 

Generally, name resolution plays an important role in the emergence and handling 
of composition conflicts. The various composition technologies necessarily relax 
conventional name resolution rules. The inclusion of an aspect or concern in a 
composition relies on a tolerant form of name matching that precludes dete ction of 
over-de fined or under-defined names. Existing tools, such as Hyper/J^*^ |[22]Jnd 
Aspect! provide no mechanisms to prevent or require the inclusion of specific 
aspects or enhancements. This issue must be addressed by advanced separation of 
concerns approaches. 

Advanced separation of concerns mechanisms must be able to identify these 
classes of conflicts among aspects that are to be composed and to address the 
conflicts, where possible. 

Motivating papers: See |[23l for intentional semantic mismatch conflicts; |[^ for 
unintentional semantic mismatch conflicts; and|Q^for spurious conflicts. 



2.2 Challenge Problems and Reqnirements 

Challenge Problem 1: Recognition, Representation and Enforcement of 

Intentional Semantic Mismatch Conflicts Among Concerns 

To demonstrate intentional semantic mismatch conflicts, we present a challenge 
problem in which aspects are used to separate distribution-related code (implemented 
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for CORBA) from problem-domain code. Separating these concerns reduces the 
complexity oftl^ code and improves its reusability^A simplified version of the code 
is shown in|Fig. l| the full version can be found in|r23l| 



import org.omg.CosNaming.*; 

import org.omg.CosNaming.NamingContextPackage.'; 
import org.omg. CORBA.'; 

aspect ServerName { 

static advice void main(String argsQ) & Server { 
after { 

ORB orb = ORB.init(args, null); 
orb.connect(ref): 

org.omg. CORBA. Object objRef = 

orb.resolve_initial_references("NameService"): 
NamingConte>ct ncRef = NamingContextHelper.narrow(objRef); 
NameComponent nc = new NameComponent{"Name". " "); 
NameComponent path[] = {nc}; Acno/'t 

ncRef.rebind(path, ref); MOfJCCl 

} 

> 

} 



ServerName 



aspect Serverstring { 

static advice void main(String args[]) & Server { 
after { 

ORB orb = ORB.init(args, nuil); 
orb.connect(ref>; 

String str = orb.object_to_string(ref); 

String fiiename = System.getProperty("user.home")+ 
System. getProperty{"fiie.separator")+"iOR"; 
FileOutputStream fos = new FiieOutputStream(fiiename): 
System.out.println(fiiename); 

PrintStream ps = new PrintStream(fos); 

Aspect 

) 

} 



Serverstring 



import org.omg. CORBA.’: 
aspect ServerComm { 



static advice void 
after { 
java. lang. Object sync = 
synchronized(sync){ 
sync.wait(): 

} 

) 

} 



in(String args[]) & Server { 

java. lang. ObJect(); 

Aspect 
ServerComm 






class Servant extends _lnterface_NameimplBase { 
public String get() { 
return "\n A String \n"; 

) Server 

’ Code 

public class Server { 
static Servant ref; 

public static void main(String args[j) { 
ref = new Servant(); 

} 

) 



Aspect Weaver 



woven Server Code 



Fig. 1. CORBA server example: Use ServerName or Serverstring but not both 



As shown in]Fi£j clients send requests to a server, which responds with a string. 
The implementation consists of four modules: ServerCode and the aspects 
ServerName, Serverstring, and ServerComm. ServerCode implements 
the server, while the aspects encapsulate CORBA-related code. 

To use a service, a client must obtain an initial reference to the server. This can be 
done either by contacting a name server, which provides the reference, or by 
accessing a disk file that contains the information, but the designer intended that only 
one of these methods would be chosen. The ServerName aspect encapsulates the 
solution based on contacting a name server, while the Server String aspect 
realizes the file-based solution. Thus, only one of these two aspects should be 
composed with ServerCode to select an approach. 

Clearly, it is not always possible for a compositor to identify circumstances like 
this one — where seemingly compatible aspects are, in fact, semantically incompatible. 
It must, therefore, be possible for a developer to specify this intentional semantic 
mismatch (mutual exclusion), and for a compositor to use this information to enforce 
the associated semantics. 
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Requirement 1 Advanced separation of concerns approaches must permit the static 
specification of concern compatibility properties, such as mutual exclusion. 
Compositor tools must understand and enforce such specifications. While automatic 
detection of all semantic conflicts is undecidable, the use of user-specified 
annotations is an example of a simple, tractable approach. 

Sample solution: Hyper/J™ |[22]| could easily be extended to express mutual 
exclusion by putting the two aspects into the same dimension and specifying that only 
one coordinate can be selected from that dimension. 

Challenge Problem 2: Recognition, Representation, and Enforcement of 

Unintentional Semantic Mismatch Conflicts Among Concerns 

Unintentional semantic mismatch conflicts arise when a set of aspects or concerns 
interact with one another in a composed program in unanticipated ways to produce 
erroneous behaviors. When unintentional semantic mismatches occur, the desired 
course of action is to deteet the conflict and then resolve it by adjusting the concerns 
or their composition. Unintentional semantic mismatch conflicts are common 
problems in software integration in general, and they are a large part of what makes 
integration a difficult problem. We believe that unintentional semantic mismatches 
will occur more commonly, and will become more problematic, as aspects and 
concerns are reused in different contexts, and as aspects or concerns written by 
different people (who may make different assumptions) are integrated. 

To demonstrate unintentional semantic mismatch conflicts, we present a challenge 
problem involving a simplified banking application (the full version is presented in 
|[8]| . The core part of the application contains a bank Account class. Two aspects 
are also defined: Event and Transaction, add event handling and transactions on 
Accounts, respectively. The Event aspect transmits events on certain channels 
whenever a significant state transition occurs on an Account. Other objects may 
then listen on those channels to be notified about such transitions. The 
Transaction aspect supports standard transaction semantics via the operations 
begin, commit, and rollback. 

When the Event and Transaction aspects are used together, they interact in 
such a way that a semantic conflict can arise if events are propagated out of 
uncommitted transactions (e.g.,^^^. For example, consider what if a client performs 
a deposit operation on an Account object, and this operation is later terminated 
by a rollback (i.e., the enclosing transaction aborts). The Event aspect may 
already have broadcast the deposit event to unknown listeners. Thus, while the 
rollback will leave the Account object itself in a correct state, the event listeners 
will not be in a correct state — they have already seen, and possibly acted upon, the 
deposit event. 

This unintentional semantic mismatch conflict can produce incorrect behavior in 
the composed program, but it can be corrected using a standard technique: delaying 
the actual broadcasting of events until the transaction commits (or suppressing the 
broadcast of events if the transaction aborts). Clearly, however, detecting and 
correcting semantic conflict problems would, in the general case, require intervention 
by a developer. 
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Requirement 2 Advanced separation of concerns approaches must provide a means 
for identifying and resolving unintentional semantic mismatch conflicts. In contrast 
with intentional semantic mismatches, which can be identified statically, 
identification and resolution of unintentional semantic mismatches may occur 
statically, at composition-time, and/or at run-time, and they may occur manually (by a 
developer), semi-automatically, and/or automatically. 

Sample solutions: One possible solution totMs challenge problem would be to use 
an approach like composition filters ITIjI which could intercept all event 
transmissions and store the events until the commit of a transaction. Even with 
composition filters, however, it would not be straightforward to make the aspects 
work together seamlessly. Another possible solution, using an extended Hyper/J, 
would be to require the Event aspect to provide certain transaction-related 
services — or, conversely, to write such services separately and compose them into the 
Event aspect — thus enabling the Transaction aspect to integrate the Event 
aspect into the transactional environment. 

Detection of Spurious Conflicts Among Concerns: The previous two challenge 
problems addressed the detection and resolution of actual conflicts among composed 
aspects. The opposite situation may also arise — namely, where a composition 
mechanism reports a conflict, even when one does not exist. 

To illustrate this situation, we consider composition mechanisms that are based on 
textual transformations from aspect languages to other languages (like Java™), and 
that then rely on compilers for the target language to compile the translated, 
composed code. In such cases, the generated code may appear to the target language 
compiler to be unsafe, even though it is type safe, because the static type analyzer in 
the target language is not sufficiently powerful to capture concepts expressed in the 
aspect languages. 

An example of this is given in Section 4 ofj^^ we describe a simpler case of the 
problem here. Consider the definition of a simple node/edge-based graph class: 

class Node { void attach(Edge e) ; } 

class Edge { boolean incident (Node) ; } 

Thus, Nodes and Edges are used together as a unit. We may also define a 
general method that operates on graphs: 

method m (Node n. Edge e) {... e . attach (n) ; ...} 

Next, assume that we define two different enhancements of this kind of graph: one 
that adds colors to nodes to pennit cycle detection, and another that adds printing. A 
given system may wish to use both colorable and printable graph instances, but it 
might not want to equip all graphs with both facilities, due to the extra performance 
and memory overhead. 

Since the method m depends only on the basic graph abstraction, not on coloring or 
printing, it should be reusable on all kinds of graphs — ^printable, colorable, both, or 
neither. Thus, we would like to include multiple aspects in different instances of a 
graph, and we would like to access all kinds of graphs polymorphically (m is 
applicable to all kinds of graphs, with or without the aspects). In standard object- 
oriented type systems, like those in C++ and Java™, it is not possible to achieve all of 
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these goals in a type-safe manner, because there are only two implementation 
approaches: 

1. Define separate, unrelated Node, Edge, ColoredNode, ColoredEdge, 

PrintableNode, and PrintableEdge classes. In this case, the Node class’ 
attach method explicitly takes Edge parameters, while the attach methods in 
ColoredNode and PrintableNode take ColoredEdge and 

PrintableEdge parameters, respectively. In this case, the solution is 

completely type-safe, but it has lost the reusability property of object-oriented 
systems: the attach methods, which were independent of the printable and 
colored aspects, are copied into all the node classes, as is the implementation of 
method m — it is impossible to write a single method that works on all kinds of 
graphs. 

2. Define ColoredNode and PrintableNode as subclasses of Node, and 
ColoredEdge and PrintableEdge as subclasses of Edge. In this case, 
reusability is maintained, but at the cost of type safety: the attach methods of all 
Node classes expect an argument of type Edge, not ColoredEdge or 
PrintableEdge. Thus, it is possible to attach a PrintableEdge to a 
ColoredNode, etc. 

In short, a spurious conflict arises if a composed program contains more than one 
aspect or concern composed with a “base” class, and if the program tries to visit 
different instances of the class — which may have different combinations of aspects or 
concerns attached to them — polymorphically. The problem is that the different 
families of classes will either be unrelated in the type hierarchy (the first case), or 
they will be indistinguishable (the second case). This means that the polymorphic 
code will be rejected by the compiler (a spurious conflict), or it will not be type safe. 

A solution to th is problem is to use more expressive type analysis, such as that 
described in |[13]| Static analysis is performed at the highest possible level of 
abstraction — the “base code” and the aspects themselves — not on composed, tangled 
code (or other artifact, like design) in an underlying lower-level representation, as 
might be produced by a compositor tool. 

Requirement 3 Implementations of advanced separation of concerns approaches 
should not lead to spurious errors, such as type errors in generated code when there 
are none in reality. Depending on the goals of particular implementations, type 
checking may be done statically (at compile- or translation-time), at composition 
time, and/or at run-time. 



3 Generic, Reusable, and “Jumping” Aspects and Concerns 

Group members: Lodewijk Bergmans, Krzysztof Czamecki, Lutz Dominick, Erlend 
Stav, Bart Vanhaute, and Kris de Voider 

Issues: The need for highly generic, reusable aspects and concerns as first-class 
reusable components, aspect and concern configuration and instantiation, syntactic 
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and semantic join point specification, and context-sensitive join point selection 
(“jumping aspects”). 

Categories: Challenge problems, requirements statements 



3.1 Problem Overview 



A key goal of advanced separation of concerns is to achieve better modularity and 
better reuse by increasing the kinds of concerns and aspects that can be separated and 
encapsulated. While better modularity has certainly been a result of much work in 
this field, the ability to reuse aspects and other kinds of concerns in different contexts 
still falls short of the goal. Achieving these goals requires: 



The ability to model aspects and concerns as first-class, reusable components. A 
key issue in achieving reusability is ensuring that concerns are not coupled — that 
is, they do not encode knowledge of, or direct dependencies on, each other (or on 
any “base” code). 

Support for both syntactic and semantic join points. “The method C . setFoo ( ) ” 
is an example of a syntactic join point that is specific to a particular class and 
method. “All methods that modify object state” is an example of a semantic join 
point that can be applied to any class. The use of semantic join points may improve 
the set of contexts in which various kinds of concerns can be reused without 
modification. It also reduces coupling among concerns. 

The ability to use both context-insensitive join points and context-sensitive join 
points. Context-sensitive join points are ones that determine at run-time, rather 
than solely at composition time, whether or not to dispatch to particular aspects or 
concerns that are composed at that join point, based on the value of some run-time 
state informatior[|| When this happens, the set of aspects or concerns that are 
composed before, after, or around a given join point may change from execution to 
execution — i.e., the concerns or aspects appear to “jump” from one join point to 
another. Note that context sensitivity can be either static or dynamic, when they 
are purely static, approaches like code duplication may be sufficient to address 
them, but when they are dynamic, they require dynamic checks to be performed. 
Context-sensitive join points may increase the circumstances under which a given 
aspect or concern can be reused. 

The ability to model multiple decompositions of software systems, to reflect the 
perspectives of different users. Of particular importance is the ability to represent 
decompositions based on user-oriented features vs. reuse-oriented components, 

aspects, and other concerns. 

A mechanism that addresses the inheritance anomaly problem This 

problem arises in languages that support advanced separation of concerns in much 
the same way as it does in concurrent object-oriented languages, and it has the 
corresponding adverse effect on reusability and encapsulation of aspects and other 
concerns as components. In particular, if a set of aspects or concerns is composed 



' The conditions for executing a given concern may actually be specified declaratively, based 
(for example) on dynamic stmctures such as call graphs and data flow, which can be also 
described statically. 
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with a class, C, then all of C’s subclasses should, at minimum, be composed with 
the same aspects or concerns. Furthermore, the introduction of new methods in C, 
or the overriding of C’s methods by a subclass, may require new aspect- or 
concern-level definitions. These new definitions may end up being invasive — that 
is, they may affect the existing ones, which is undesirable and which may cause 
unexpected errors. 

Motiva ting papers: See |[12]| for a discussion of issues in defining generic, re usable 
aspects, t71| for a full description of the jumping aspects problem, and |[l91|[20'| for an 
analysis of the inheritance anomaly in concurrent object-oriented languages. 



3.2 Challenge Problems and Reqnirements 

Challenge Problem 3: Highly Reusable, Configurable Aspect and Concern 

Components 

To demonstrate some of the key issues in, and requirements on, making aspects and 
concerns first-class, reusable, configurable components, we use running example that 
starts with a simple stack in C++ (taken from l'l llj : 

Template<class Element_, int S_SIZE> 
class Stack { 
public : 

// export element type and empty and maximum top 
// value 

typedef Element_ Element; 
enum { EMPTY = -1, 

MAX_TOP = S_SIZE-1}; 

Stack 0 : top (EMPTY) {} 

void push(Element *element) { 
elements [++top] = element; 

} 

Element *pop ( ) { 

return elements [top--] ; 

} 

protected: 
int top; 
private : 

Element *elements [S_SIZE] ; 

} ; 

To use this stack in a multithreaded environment, concurrent access to stacks must be 
synchronized. In particular, three synchronization locks are needed: one to provide 
mutually and self-exclusive access to the push() and pop() methods, and the other two 
to implement synchronization guards for threads that are trying to push an element 
onto a full stack, or to pop an element from an empty stack. The push() and pop() 
methods must be made to use these locks appro priate ly. 

A key idea of aspe ct-orie nted programming |[ 1 8ll composition filters EHl subject- 
oriented programming and other work in the advanced separation of concerns 
area is that manually mixing concerns, like synchronization code, into the source 
implementation of pop() and push() of the original stack is a bad idea — it resu lts in 
tangled code, which is hard to understand and to maintain, as shown in|[n]|(page 
280). In addition, the invasive modification produces just a synchronized stack, 
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although having both a synchronized and unsynchronized stack might have been 
useful. 



Requirement 4 Advanced separation of concerns mechanisms must permit 
developers to implement synchronization code (as well as any other “cross-cutting” or 
other kind of concerns) separately from any code to which it may apply. 

Sample solutions: A simple solution to this problem in a standard object-oriented 
language might be to use inheritance to separate the synchronization aspect. In this 
case, we could derive a subclass of class Stack, which defines the necessary locks 
and refines the push() and pop() methods fro m the superclass by wrapping them into 
the necessary synchronization code (also fromQlJJ: 

template<class Element_, int S_SIZE> 
class Sync_Stack : public Stack<Element_, S_SIZE> { 
public : 

typedef Stack<Element_, S_SIZE> UnsyncStack; 

// get the element type and empty and maximum top value 
typedef typename UnsyncStack: : Element Element; 
enum { EMPTY = UnsyncStack: : EMPTY, 

MAX_TOP = UnsyncStack: :MAX_TOP }; 

Sync_Stack() : UnsyncStack () , 

push_wait (lock) , 
pop_wait (lock) { } 
void push(Element *element) { 

ACE_Guard<ACE_Thread_Mutex> monitor ( lock) ; 
while (top == MAX_TOP) push_wait . wait ( ) ; 

UnsyncStack: : push ( element ) ; 

} 

Element *pop ( ) { 

Element *return_val; 

ACE_Guard<ACE_Thread_Mutex> monitor ( lock) ; 
while (top == EMPTY) pop_wait . wait ( ) ; 
return_val = UnsyncStack: : pop () ; 

return return_val ; 

} 



} 

This kind of solution effectively separates synchronization from the core stack. The 
major limitation of this solution is that existing clients, which use the Stack class, 
must be modified to instantiate the new class, Sync_Stack, instead of Stack. The 
standard object-oriented solution to this problem is to use factories in the client code, 
but this implies that the client code anticipated such a change and used factories to 
start with. This kind of “anticipatory generality” is responsible for much of the 
complexity in object-oriented code and frameworks. Unfortunately, the predictions 
are often wrong and much of the complexity turns out to be unnecessary. A solution 
to this problem is the use of a composition mechanism, which, unlike inheritance, 
facilitates the extension of classes withouHnvalid^ng client code. This permits non- 
invasive changes without pre-planningir 1 6'|22'|25l| 
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Requirement 5 Approaches to advanced separation of concerns should provide 
composition mechanisms that permit the addition of new aspects or concerns to 
existing code non-invasively, without invalidating existing clients, and without pre- 
planning, to whatever extent possible. 



At some later date, a developer discovers the need for a FIFO (first-in, first-out) 
queue to implement a communication buffer in a multi-threaded application. Clearly, 
the synchronization aspect developed for the stack is exactly the same as the one 
needed for the new FIFO queue. This suggests the need for a generic, reusable 
synchronization aspect. 

Sample solution: One way to convert Sync_Stack into a reusable aspect is to 
model it as a parameterized type: 

template<class Queue> 

class Synchronizer : public Queue 

{ - . - } 

This synchronization aspect can be instantiated for either a stack or a queue: 

Synchronizer<Stack> 

Synchronizer<FIFO_Queue> 



This solution, like Sync_Stack, suffers from the pr oblem that it r equires an 
invasive modification to client code to use it. A solution to Requirement 5| would also 
address this problem. 



Requirement 6 Advanced separation of concerns mechanisms must provide a means 
of representing generic concerns, which can be specialized for use in different 
contexts. Parametric types are one example of a means of specifying and specializing 
concerns. 

A significant limitation of the Synchronizer aspect above is that is relies on a 
consistent set of method names — for example, it assumes the presence of methods 
push() and pop(), which is wraps to achieve synchronization. In practice, however, a 
developer might prefer to call the corresponding methods “enqueueO” and 
“dequeueO”. Further, the Synchronizer aspect should also be applicable to other 
methods that a synchronized class might define. For example, a queue class might 
define a method size(), which should be mutually exclusive with operations that 
modify the queue. This suggests that to produce truly generic, reusable aspects and 
concerns, developers must be able to define semantic categories for join points, such 
as “read-only methods,” “adding methods,” and “removing methods,” rather than 
simply syntactic join points, such as “the push() method” and “the pop() method.” In 
the synchronization example, we might choose to define the following semantic 
categories: 

ADD category: ADD is self exclusive, and the buffer is not FULL 

READ category: no ADD or REMOVE is busy 

REMOVE category: REMOVE is self exclusive, and the buffer is not EMPTY 
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Requirement 7 Advanced separation of concerns mechanisms must provide a means 
of defining semantic join points, as well as syntactic join points. 

Challenge Problem 4: The Inheritance Anomaly 

The concept of general, reusable aspects, as presented in the previous challenge 
problem, suffers from the same “inheritance anomaly” problem that was ident ified in 
the domain of concurrent object-oriented programming languages |[20]| The 
inheritance anomaly in that domain occurs when developers attempt to write 
subclasses of classes that contain synchronization code. When these subclasses 
override individual methods defined in their superclasses, they generally must 
redefine (or just copy the implementation of) all of the synchronization code 
contained within the superclass’ method. 

In the context of advanced separation of concerns, the inheritance anomaly 
problem manifests itself in much the same way as in concurrent languages: subclasses 
should inherit any aspects or concerns that are composed with their superclasses^ 
Moreover, the introduction of new methods, or the overriding of superclass methods, 
may require additional aspect or concern definitions. These new definitions should be 
non-invasive — that is, they should not affect existing aspect or concern definitions. 

The general solution to the inheritance anomaly in concurrent languages requires 
developers to define semantic categories on which the synchronization requirements 
can be expressed. Mappings between object states and the semantic categories are 
then defined. The object states, the semantic categories, and the mapping between 
them are kept separate. A similar approach is one way to address the inheritance 
anomaly in advanced separation of concerns mechanisms. 

To illustrate the inheritance anomaly and one solution approach in the context of 
advanced separation of concerns, we return to the stack/queue example from the 
previous challenge problem, in which a generic producer/consumer synchronization 
aspect was defined. As described earlier, the synchronization constraints are specified 
with respect to categories of method calls, and thus, they pertain to many possible 
concrete representations (stacks, queues, lists, etc.). The set of semantic categories 
described were: 

ADD category: no READ or REMOVE is busy, and the buffer is not FULL 
READ category: no ADD or REMOVE is busy 

REMOVE category: no ADD or READ is busy, and the buffer is not EMPTY 

For each concrete representation, like a stack or queue, a mapping must be defined 
between these categories and the concrete methods of the representation, and between 
the categories and concrete object state. For example, for the stack, we might define: 
push(Element) — > ADD 
peek() READ 
popO REMOVE 
FULL == (top == size+1) 

For a queue, the mapping might be: 
enqueue(Element) ^ ADD 



^ In fact, synchronization is simply one example of an aspect that might be composed with a 
class whose subclasses should have the same synchronization aspect composed with them. 
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dequeueO ^ REMOVE 
FULL == (head == tail) 

EMPTY == (tail+1 % size = head) 

These mappings could then be used as join point specifications for a compositor, 
which would compose the synchronization code appropriately with the stack and 
queue. 

Other proposals for addressing the inheritance anomaly in concurrent languages 
also exist and could likely be adapted for use in the context of advanced separation of 
concerns. 

Requirement 8 All advanced separation of concerns approaches for object-oriented 
languages (and other languages that include behavioral polymorphism mechanisms) 
must address the inheritance anomaly in some way. Further, any concerns that are 
composed with a class should also be composed with its subclasses. It should be 
possible to adapt “inherited” concerns for any subclass without affecting the 
superclass, just as it is possible to adapt superclass methods in a subclass without 
affecting the superclass. 

Challenge Problem 5: “Jumping Aspects” in Model-View-Controller Change 
Notification 

The previous two challenge problems addressed some significant issues in providing 
support for highly generic, reusable, configurable aspects and other concerns, 
including the need to specify semantic join points. This problem highlights another 
major issue: the need to specify dynamic join points. 

To illustrate this issue, we use the Smalltalk Model- View-Controller pattern. In 
Smalltalk applications, it is common practice to separate the representation of an 
object from its presentation using MVC. In MVC, a View must be notified of any 
change in its Model. To accomplish this, the model must invoke the method 
changed (i.e., self changed) from every method that changes its state. This 
results in the propagation of an update event to all views of the model. Change 
notification, in the form of self changed calls, represents an aspect that can be 
composed into ListModel methods that change the model state. 

Two methods from a Model for a List class are shown below: add, which adds 
a single element to a list, and addAll, which adds multiple elements at the same 
time: 



ListModel>>add : anElement 

myElements at: currentindex put: anElement. 
currentindex := currentindex -i- 1. 
self changed. "***aspect code for change 
notification" 

ListModel>>addAll : aCollection 

aCollection do: [ : each | self add: each]. 

This naive implementation results in poor performance, however, because change 
updates occur each time addAl 1 uses add to insert a new element into the list. The 
best solution is for addAll to invoke self changed itself, and for add to call 
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self changed only if it is invoked by an external ListModel client, and not if 
it is invoked by addAll or other ListModel methods. Thus, add performs 
different actions — it includes or excludes the change notification aspect — depending 
on from where it is called: 

For calls that occur directly to add from outside ListModel: 

ListModel>>add : anElement 

myElements at: currentindex put: anElement. 

currentindex := currentindex + 1. 

self changed. "***aspect code is included" 

For calls to add that occur from addAll, the aspect code “jumps” to the 

calling context 

ListModel>>addAll : aCollection 

aCollection do: [ : each | self add: each] . 

self changed. "***aspect code is included" 

ListModel>>add: anElement 

myElements at: currentindex put: anElement. 
currentindex := currentindex + 1. 

"***no self changed when called through addAll" 

Synchronization code that obtains and releases locks upon entering and exiting 
methods, as in Challenge Problem ^ is also an example of jumping aspect code, 
because once a lock has been obtain^ nested calls made from within the method that 
obtains the lock need not execute the code to obtain the lock, because they obtain it 
from the method that calls it. 

These examples suggests the following requirement on advanced separation of 
concerns mechanisms: 



Requirement 9 Static join points, such as method names, cannot themselves always 
specify the location at which aspects or concerns are to be composed. For context- 
sensitive compositions (“jumping aspects”), it is necessary to specify join points and 
the (possibly dynamic) context in which the composition should occur, and to provide 
any associated declarative, compositor, and run-time support needed to enable 
compositions to be affected by context-sensitive conditions. Such mechanisms must 
handle aspects that jump either within a class or across multiple classes. 



4 Modularization and Evolution Using Advanced Separation of 
Concerns 

Group members: Jean Paul Arcangeli, Isabel Brito, Robert Filman, Eric Hilsdale, 
Donal Lafferty, Bert Robben 

Issues: Non-invasive addition of new concerns or aspects to an existing software 
system; ease of evolution in the presence of advanced separation of concerns; the 
need for dynamic join points; the need for context-sensitive join points (the “jumping 
aspects” problem — see also Section^ 

Categories: Challenge problems, requirements statements 
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4.1 Problem Overview 

A fundamental principle of software engineering is that systems that can be separated 
into (relatively) independent parts are simpler to develop, and easier to maintain and 
evolve. Traditionally, this separation has been about the primary functionality of 
systems — related functionality would be grouped into objects or components, with 
well-defined interfaces between elements. The key hypothesis of this work is that 
other separations are possible; that technologies can be created that allow separate 
expression and development of non-functional concerns while still yielding efficient, 
working systems. Several characteristics of any particular approach to advanced 
separation of concerns affect that approach’s ability to provide these additional 
modularization and evolution benefits; 

- How well the approach separates the expression of different facilities. 

- Whether or not specifying a new concern can be done non-invasively — i.e., the 
new concern does not require any existing code to be changed (“core” functionality 
or other concerns or aspects). 

- The kinds of join points the approach supports for composition, including context- 
sensitive join points (as described in Section|^, dynamic join points, and class- vs. 
instance-based join points. 

- How well the approach can limit the impact of an evolutionary change to a given 
concern or aspect on the rest of the system, and how the change is effected (e.g., 
stop the system, recompile it, and rerun it vs. on-line evolution). 

- How readily the approach facilitates the representation of some key kinds of 
aspects, such as synchronization. 

M otivat ing pape rs: The challenge problems reported in this section were motivated 

by |ri4i| and r^ 

4.2 Challenge Problems and Reqnirements 

This set of challenge problems is based on variations of an example involving mobile 
agents that visit servers. These agents wander the web, attempting to accomplish 
some task. In pursuit of their goals, they need to execute programs on servers. 
Sometimes these agents must share information with one another. They do so using 
“coordination loci,” through which they can communicate results and task 
assi^ni^nts. 

^ig^j presents a high-level architecture for such a mobile agent system. In this 
architecture, servers respond to two kinds of messages: 

3. enter (program) ^boolean: This method used is by an agent to dock at a 
new remote server. It returns true or false, depending on whether the remote server 
accepts the agent. 

4. query (string ) ^string: This method is used to obtain information from the 
server with which an agent is docked. Servers only accept queries from agents that 
are docked with them. Note that some of the strings that are passed to, or returned 
from, a query method may encode object references, as is the case with lORs in 
CORBA. (In the absence of this facility, one could define a “name server” that 
converts strings to object references.) 
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Fig. 2. High-level architecture for the mobile agent system. 



Agents are subclasses of coordination loci. Both support the note method, which 
is used to communicate arbitrary information. Agents can enter servers, query 
servers, and send messages to, and receive messages from, coordination loci via the 
note method. 

The following series of challenge problems work from the assumption that there is 
already an existing implementation of this mobile agent system. Since we are 
interested in software systems evolution, each challenge problem requires either the 
addition of some new capability to, or the modification of an existing capability in, 
the system. 

Challenge Problem 6: Security in Mobile Agent Systems 

To introduce security into the mobile agent system, it is necessary to incorporate the 
concept of agent identity into the system, and to use it as needed to ensure that agents 
only have access to the servers and information to which they are permitted. Agent 
identity means that each agent must have an identifier (its “identity”), which allows it 
to be distinguished from all other agents in the system. (Think of this as the identity 
of the user that spawned the original request.) The agent identifier is used to enforce 
several security policies: 

- “Spawned asent” equivalence '. When a given agent executes the enter method 
on another server, it spawns a new agent that runs on that server. The spawned 
agent should be treated the same way as the original — that is, it should have the 
same identity as the spawning agent. Servers may then choose to accept or reject 
an enter request based on the identity of the calling agent, as well as on any 
other factors they deem appropriate. 

- Restricted queries : Servers should only process query requests from entered 
agents. Further, the set of queries that any given agent can run may be restricted. 
Based on the identity of a given agent, a server should be able to reject the query 
(e.g., by raising an exception or returning an error code that indicates the 
requesting agent does not have permission to issue that query), filter either the 
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contents of the query to make it acceptable or the results of the query before 
returning them, or simply service the query request as-is. 

The addition of the new identity concern should be done non-invasively — that is, 
its definition s hould not require any modifications to the existing system 
dlequirement 5] . 

The ability to restrict queries illustrates the “jumping aspects” problem (Section^. 
Therefore, it also illustrates the need for context -sensitive join points, where the 
agent’s identity is the required context information (j^e^uirement^] . It also, however, 
implies the following additional requirements: 



Requirement 10 Compositors must be able to examine method parameter values and 
return values as part of the information they use to determine whether or not to 
execute particular concerns or aspects at a given context-sensitive, dynamic join 
point. 



Requirement 11 Advanced separation of concerns mechanisms must provide the 
ability for one concern to guard the execution of code at any given join point (e.g., a 
method) that belongs to other concerns, including “base” code. 



Challenge Problem 7: Concern Dynamics 

Security policies may change over time. Consider what must be done to change the 
behavior of a concern. There is a wide spectrum of approaches to replacing concerns 
or aspects, ranging from completely static mechanisms to completely dynamic ones, 
and each point on the spectrum has its own advantages and disadvantages. For 
example: 

- Completely static . An example of a completely static approach is one that entails 
terminating the execution of the composed mobile agent system or some 
components of it, recompiling and/or recomposing the affected parts, and restarting 
the program or subcomponents. A key advantage to this approach is that it is 
statically type checkable and it imposes little run-time overhead — the cost of 
composition is primarily a compile-time one, which may be particularly 
advantageous to performance-critical applications. A major disadvantage, in some 
contexts, is that it necessitates the termination and restarting of the running 
software. 

- Completely dynamic : A completely dynamic mechanism might include a means of 
replacing a concern in-plac e, w hile the composed program is running, as in the 
case of composition filters [l]| and reflective and interpretive approaches. This 
type of approach is considerably more flexible and also provides the richest set of 
context-sensitive and dynamic join points, but it may result in deferring the 
identification of some kinds of errors to run-time, where they cost more to detect, 
and it may impose more run-time overhead (for the additional error-checking and 
to enable dynamic changes to a running executable). 
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Requirement 12 Many points on the static<Adynamic spectrum of approaches to 
concern replacement exist, each representing different tradeoffs. Ideally, any given 
approach to advanced separation of concerns should address multiple points on the 
spectrum, if possible, or it should clearly be specialized for a target domain in which a 
single point is clearly the best one. 

Challenge Problem 8: Synchronization in Mobile Agent Systems 

So far, the mobile agent system has assumed that only single messages are sent to 
coordination loci at any given time. Clearly, a given agent may have to send a series 
of “notes” to a coordination locus, and to do so without interference from any other 
agents. This challenge problem includes two variants of this problem: 

- Lockins '. If an agent needs to send a series of messages to a single coordination 
locus without interference, standard locking of a coordination locus permits agents 
to have exclusive access to the locus while they send a series of “notes.” Locking 
represents a new concern in the system. 

- Transactions '. While locks permit exclusive access, they generally do not provide 

properties such as atomicity or serializability — ^properties associated with standard 
transactions. Further, locks do not provide a good means of permitting agents to 
send a series of messages to multiple coordination loci. Thus, standard 
transactions over coordination loci should be supported as an additional concern. 
Note that, unlike locks, transactions affect the existing mobile agent system in 
some fairly deep ways. For example, the mobile agent system will have to be 
enabled for transaction abort, rollback, and logging, which affects most of the 
methods in the “base” system. Further, transactions may interact with other 
aspects or concerns as well, necessitating changes to them to permit the 
transactions to preserve the ACID (atomicity, consistency, isolation 

[serializability], and durability [persistence]) properties. 



Requirement 13 Some kinds of concerns, like transactions, interact with others. An 
advanced separation of concerns mechanism must permit the composition of concerns 
with other concerns, and must provide a non-invasive means for concem-to-concem 
interactions, as well as concem-to-“base” interactions. 

Challenge Problem 9: Dynamic Join Points in Mobile Agent Systems 

To this point, all of the aspects or concerns that have been added to the mobile agent 
system were intended to be composed at the class level. This challenge problem 
highlights the need for composition at the method and instance level as well. In 
particular, it illustrates the need for dynamic join points. 

The first part of this challenge problem operates at the method level. It involves 
the introduction of a debugging mechanism to the mobile agent system, which sends a 
note to a specific coordination locus upon every query. 
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Requirement 14 Advanced separation of concerns approaches must provide a means 
of composing new behaviors into some set of functions in an existing code base. 
Ideally, it should be possible to select the set of functions using a fairly rich 
specification notation (e.g., regular expressions). 

The second part of this challenge problem involves the introduction of the same 
debugging code on a specific agent, and on all of its descendants (its spawned agents). 
In this case, the intent is to compose the debugging behavior into a set of instances. 
We specifically exclude approaches in which the debugging concern performs a 
lookup on each agent that runs a query to see if it is supposed to run the debugging 
code, because doing so imposes a number of localization/failure problems on the 
distributed mobile agent application. 

Note that the selection of instances with which to compose behaviors is an example 
of the need for dynamic join point selection (as distinguished from context-sensitive 
join points). 



Requirement 15 Advanced separation of concerns approaches must provide dynamic 
join points as well as static. Dynamic join points must also provide the ability to 
compose new behaviors into some set of instances. This mechanism should not 
require an aspect or concern to keep track of all instances, or of all instances that 
should have the behavior. 



5 Exception Handling and Timing Constraints 

Group members: Andrew Black, Maja D'Hondt, Wolfgang De Meuter, Mik Kersten, 
Oscar Nierstrasz, J. Andres Diaz Pace 

Issues: The need for context-sensitive join points in exception handling and systems 
with timing constraints. 

Categories: Challenge problems, requirements statements 

5.1 Problem Overview 

The need for context-sensitive join points (described in Section ^ arises in many 
areas in software engineering, including some non-obvious ones like exception 
handling and systems with various kinds of timing constraints (including real-time). 
These issues are critical. The reusability of a given component depends, in part, on the 
encapsulation of exception and failure processing as coherent concerns, because how 
a component handles exceptional conditions and failures often varies from one usage 
context to another (e.g., in one context, it may be appropriate to throw exceptions 
upon detecting an erroneous condition, while in another, it may be necessary to take 
corrective actions, and the corrective actions may also be usage- and/or context- 
specific). The ability of components to satisfy timing constraints is also affected by 
the ability to separate the usage context from time-critical concerns. 

Motivating papers: The “jumping aspects” problem is identified in ^7]j The 

particular need for advanced separation of concerns to address issues in satisfying 
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timing constraints was originally described in but its classification as a “jumping 
aspect” problem was established during the wottonop. 

5.2 Challenge Problems and Reqnirements 

Challenge Problem 10: Context-sensitive exception and failnre handlin g 

The need for context-sensitive exception handling is described in |[7]| as a 
manifestation of the “jumping aspects” problem. Consider a component that can be 
used either as a stand-alone application or by a larger application. Thus, this 
component may be used in different contexts with different requirements. Among 
these differences are: 

- Error condition definition '. Different applications may define what constitutes an 
“error” differently. For example, one application may consider it an erroneous 
condition if a lookup on a hash table fails to find an element with the given key; 
another application may be coded to assume that not all queries will find a 
matching element, and that if no matching element is found, a “null” reference will 
be returned. The ability to specify error conditions separately from any component 
that may recognize those conditions as erroneous is critical to being able to reuse 
components in multiple contexts. 

- Error handlins '. Once an erroneous condition is detected, different applications 
(or, more generally, different usage contexts) must be able to specify how to 
respond to that condition. 



Requirement 16 Any approach to advanced separation of concerns must permit the 
encapsulation of exception detection and handling as separate concerns. At 
minimum, such mechanisms must provide the ability to encapsulate as separate 
concerns both the condition that denotes the exceptional event, and the response to 
such a condition. Since both the definition of “exceptional evenf ’ and the response to 
it can vary between dif ferent usage con texts, it is necessary for a solution to this 
requirement to address p.equirement 9||(i.e., soluti ons must provide dynamic and 
context-sensitive join points) and | p.equirement 11 [ (solutions must permit “guards” 
around join points). 



Sample solution: We can hypothesize an aspect-oriented exception handling 

mechanism where one can declaratively state that “if method x fails in concern A, then 
execute method y in concern B." The advantage of such an approach is the separation 
of the failure concern, consisting of what could go wrong and how to address it, from 
other functionality. A language that realizes this failure concern should be able to 
express what might fail and where (e.g., corresponding to throws statements in 
Java^*^), as well as where and how to resolve the conflict (e.g., corresponding to try- 
catch statements). Notice that the context-sensitivity here arises from the requirement 
that the component be able to run both on its own and as part of other applications. If 
it runs on its own, it should handle exceptional conditions itself, whereas if it runs as 
part of another application, the exceptions should propagate to the application to be 
handled there. This results in the need for context-sensitive, dynamic join points. 
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Challenge Problem 11: Time in Information Flow 

The domain of this challenge problem and the next is real-rate systems (described in 
|[6ll , where data is moved from one location to another at defined rates. Example 
systems in this domain are audio conferencing and streaming video. A general 
characteristic of real-rate systems is that they usually deliver data (such as audio or 
video frames) from a source (usually a server or file system) to a sink (e.g., a display 
or a sound generator). A key requirement on such systems is that the data must arrive 
periodically, with constrained latency and jitter. Such systems are difficult to design 
and construct, which suggests the nee d fo r generalization of these issues into an 
information flow framework. InfoPipes ^]is such a framework, which enables the 
building of real-rate systems from pre-defined components such as buffers, pipes, 
filters and meters. Properties such as latency, jitter and data-rate of the resulting 
pipeline are calculated from the corresponding properties of the components. In the 
development of the InfoPipes framework, the components naturally mapped onto 
objects: there are objects representing bounded and unbounded buffers, straight pipes, 
sources, and sinks, where each of them has zero or more inputs and outputs. A 
properly connected pipeline consists of a set of connected components; each 
component’s inputs are connected to an output of another component. 

An important concern in infonnation flow is time: the flow of data through the 
pipeline is subject tohard timing constraints. Consider, for example, the simple 
pipeline illustrated in^g^ the server can provide audio frames at a certain rate, via 
a network with variable rate, either directly to a sound generator or via a 
decompressor. Both the decompressor and the sound generator must be supplied with 
audio frames at a determined rate. Suppose that the network’s rate decreases 
considerably, causing a violation of the decompressor’s and the sound generator’s 
required rates. If the audio frames must flow via the decompressor, then the 
decompressor must handle this violation (e.g., by resending the last audio frames). If, 
on the other hand, the frames go directly to the sound generator, the sound generator 
must handle the violation. Therefore, the timing failure concern “jumps” in and out of 
the sound generator’s code that handles the receipt of audio frames, depending on 
whether the caller of this code is the network or the decompressor — i.e., it is context- 
sensitive. 




Fig. 3. An InfoPipe pipeline for a sound-streaming application. 



This challenge problem clearly demonstrates ^£^uiremen^_9| It also imposes the 
following requirement: 
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Requirement 17 Advanced separation of concerns approaches must separate the 
specification of concerns from the specification of when, and to what, those concerns 
apply. That is, it must be possible to separate the specification of a concern from the 
specification of the contexts in which it is applicable. It should be possible, for 
example, to write a generic mechanism that handles violations of timing constraints, 
and to specify separately the join points at which that mechanism should be 
composed, or the circumstances under which it should be composed. For the same 
reason that object-oriented languages incorporate dispatch mechanisms based on an 
object’s run-time type instead of forcing developers to implement “typecase” 
structures (i.e., extensibility via polymorphism), it is critical that developers not be 
required to implement “concern case” structures. 



6 Multiple Views 

Group members: Thomas Kiihne, Cristina Lopes, Mira Menzini, Renaud Pawlak, 
Eddy Truyen 

Issues: The need for multiple levels of abstraction and stepwise refinement |[29]jin 
advanced separation of concerns; the need for dynamic, context-sensitive join points; 
the need for fine-grained access control. 

Categories: Challenge problems, requirements statements, problem generalization 

6.1 Problem Overview 

Many changes to a software system can be made without knowledge of the full details 
of the system’s implementation. It is desirable to permit developers to work at the 
highest level of abstraction possible and to facilitate navigation between different 
levels of abstraction as needed, sin ce doi ng so reduces the complexity of development 
tasks and promotes comprehension^^ 

The interactions among different components also appear different at different 
levels of abstraction, just as the components themselves do. Thus, the ability to 
model and navigate among different levels of abstraction effectively depends on the 
ability to describe both components and their interactions at different levels of 
abstraction. 

Access control provides yet another view of a system. A given object. A, sees a 
view of another object, B, depending on the class of B and on the access privileges of 
^’s owner (e.g., the user who created A). It must be possible to protect parts of 
objects against unauthorized access. 

Motivating papers: The need for multiple level s of a bstractions is taken from |[4]j 
The dyna mic w rappers solution is adapted from The access control issue is 

raised in [2^ and also illustrates the need for context-sensitive join points (the 
“jumping aspects” problem, described Section^. 
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6.2 Challenge Problems and Requirements 

Challenge Problem 12: Multiple Levels of Abstraction in Software Systems 

The need for multiple levels of abstraction in software is illustrated by a simple piece 
of software that writes data to a file. At the highest level of abstraction, at which all 
implementation details are omitted, the system has three ab stractions: a Writer, 
which needs to write Data to a File, as illustrated in^ig^] 




Fig. 4. Highest-level abstraction of file writer software 



Notice that the write method takes a single parameter — the data to be written. 
Moving down one level of abstraction, however, it become s clear that a 
File_Manager actually controls access to files, as shown in|Fig. 5| 




Fig. 5. Design-level abstraction: Access through a file manager 



Although the basic interaction between components is the same as that shown in ^i^ 
|l, two significant changes are apparent: 

- The server has a different identity. It is now a file manager, rather than a file 
object. 

- The write function now takes two parameters instead of just one: a file identifier, 
and the data. 

Proceeding down still another level of abstraction to add implementation details 
reveals that file managers are actualW_di^ributed components — that is, clients must 
access them remotely, as depicted in f ig. 6 \ 

Notice that the direct interaction between clients and file managers has been 
replaced by an interaction between object request brokers (ORBs) and the necessary 
client/ORB and server/ORB interactions. Further, the name of the function called by 
the Writer changed from write to request and now includes three parameters instead 
of two — the first parameter indicates which service is required. 

Many additional details might appear in lower levels of abstraction — for example, 
the communication between ORBs might require encryption. 

Note that the interactions among components may potentially be scattered across 
different subsystems. This characteristic clearly identifies this problem as one that 
requires advanced separation of concerns. 
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Fig. 6. Implementation-level abstraction; Distributed file management in CORBA 



This challenge problem demonstrates an important requirement on advanced 
separation of concerns approaches; 



Requirement 18 Advanced separation of concerns mechanisms must provide a means 
of providing multiple related views of a system. Multiple views permit the 
representation of different levels of detail for both the components that are modeled 
and their interactions. Such a mechanism must also provide a means of relating the 
views to one another, to permit navigation among them. Approaches must provide 
both modularity and flexibility. Modularity is required to permit the representation of 
the incremental changes that comprise a stepwise refinement. These incremental 
changes must be represented as a coherent module (either logical or physical). 
Flexibility is needed to permit selection — possibly dynamically — among a set of 
possible implementations, and thus, it also illustrates the need for a range of static to 
dynamic composition (see (Requirement 12] . 



Sample solutions: The “stratified architecture” approach, described in[^| directly 
ad dresses the problem of how to support multiple levels of abstr action. As dep icted 
in^igj different levels of abstraction are defined, wherelFig^through^ig^^show 
the contents that might appear at particular levels. The relationships among different 
levels of abstraction are also defined using refinement patterns. 

A different possible solution, called dynamic wrappers, is presented in |~28l| This 
approach particularly attempts to address the need for flexibility by permitting the 
building of systems as dynamic compositions of different interaction refinements (a 
means of modifying component interactions by intercepting and modifying messages 
flowing between the components). It permits the design of a system using a 
component-oriented methodology that decouples the type of a component (its 
specification or in terface) from its implementation, so that the two can vary 
independently Interaction refinements are defined by wrapping the component 
type, using the Decorator pattern A “variation point” (a context-sensitive, 

dynamic join point — see Section|^ manages the wrappers and decides, based on an 
externally specified composition policy, which wrappers (and thus, which interaction 
refinements) to invoke, and in which order to invoke them. Interactions between 
component types are reified into a basic interaction flow and a context flow. The 




228 



Peri Tarr et al. 





1} 




Fig. 7. A stratified architecture. 



context flow carries the compositi on poli cy that was specified for that interaction. 
Dynamic wrappers are illustrated in|Fig. 8| 



ComponentType 
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Component 




Wrapper 


Implementation 







Fig. 8. The dynamic wrappers approach. 



The dynamic wrappers approach permits dynamic selection among 
implementations for a given data type. For example, it allows clients to choose 
implementations that either do or do not encrypt their data as it is sent to the file 
manager. Here, encryption and decryption of data can be seen yet another interaction 
refinement that is integrated selectively — and dynamically — whenever necessary. 

The main disadvantage to the dynamic wrappers approach is that it does not satisfy 
the requirement for modularity well. The implementation of an interaction refinement 
involving several wrappers simultaneously could not be modularized well using this 
approach. 
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Challenge Problem 13: Access Control 

This challenge problem demonstrates the need for access control in advanced 
separation of concerns. The problem involves the introduction of authorization 
features into an existing television broadcast planning system [24]. Both short- and 
long-term planning of broadcast programming are business-critical information; thus, 
access to this information should be restricted to a limited subset of employees. Each 
product (e.g., a movie, series, or program) is assigned a status, and each employee is 
assigned a role in the broadcast planning process. Users are either granted or denied 
access to particular product information (which they access through various tools, 
such as a GUI or a report generator) based on their particular role, on the product’s 
status, and on the tool that is used to access the information. 




Fig. 9. Accessing authorized data in the television broadcast planning system. 



Fig. 9 summarizes this scenario. As it suggests, access privileges to the data (B) 
are determined based on both the tool that attempts to access the data (A) and on the 
role of the user who is running the tool (C). Note that some portions of the tool may 
be inaccessible to certain kinds of renderings — for example, a particular user may, in 
principle, be able to view a piece of data with a GUI, but, for security reasons, that 
data may not be accessible using the report generator, which might send it to a printer 
where it would be vulnerable to unauthorized access. 

Note that this problem also illustrates the need for context-sensitive join points 
(Section 210), where the context, in this case, include the access rights of the user and 
of the tool that are attempting to access the data, as well as the data itself and its 
particular status; it therefore also imposes Requirement 9. In addition, it suggests the 
following requirement: 



Requirement 19 Advanced separation of concerns mechanisms must provide a means 
for a single component (object, etc.) to provide different interfaces for different 
clients or categories of clients, and it must enforce correct usage of such interfaces. 
Correct usage might be determined statically, dynamically, or both. 

A suitable solution to Requirement 9 should also address Requirement 19. 
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Sample solution^ The stratified architecture approach could be used to address this 
problem. With this approach, developers first implement the broadcast planning 
system without authorization, and then annotate those relationships that involve 
authorization. Next, developers must define the refinement patterns that govern the 
transformation of these annotated relationships and their components into a different 
set of relationships and possibly additional and/or altered components. 

An Aspect J [18] solution might entail the use of the “cflow” construct, which 
indicates the identity of the initiating caller (the user, in this case). Given this 
information, it would be possible to check the access rights of the user. Note that this 
approach actually uses context-sensitive join points to address this challenge problem. 

The dynamic wrappers approach, as depicted in Fig. 10, might define a component 
type for each of the entities depicted in Fig. 9. A component type specifies the 
service interfaces and dependencies that components of this type have. None of the 
implementations of these component types contains any authorization code. Instead, 
authorization is implemented using a set of wrappers. Wrappers for the GUI type and 
the Report type each implement a customized authorization strategy. Note that 
propagation of user identification and access rights does not occur automatically; 
instead, it must be implemented by a third wrapper, for the User type, which adds user 
identification and privileges to the context flow of the reified interaction. 




Fig. 10. Using dynamic wrappers to solve the authorzation challenge problem. 



7 Context-Dependent Specialization of Existing Behavior 

Group members: Johan Brichau, Pascal Costanza, Gregor Kiczales, Elke 

Pulvermueller, Patrick Steyaert, and Tom Tourwe 

Issues: The need for context-sensitive and dynamic concerns and join points; the 
object identity problem. 

Categories: Challenge problems, requirements statements 



^ A word of caution is in order here. The original problem, as defined in [24], is considerably 
more complex than the simplified version given here. Thus, some of the sample solutions 
may not scale up to the original problem. 
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7.1 Problem Overview 

In some cases, a given component’s behavior may have to be specialized based on 
run-time context information. In particular, at some join point, a component may 
need to incorporate (i.e., be composed with) one or more aspects or concerns; those 
aspects or concerns may need to be executed, executed differently, or not executed at 
all, depending on the dynamic context in which the component is used. This is a 
manifestation of the “jumping aspects” problem (see also Section 3). 

A common manifestation of this problem occurs in the presence of delegation (the 
Decorator pattern [15]). Depending on the usage context of a wrapped object, it may 
be desirable to treat it either as having a wrapper or not. This problem has been 
referred to as the “object identity” problem. 

Motivating papers: The need for context-sensitive and dynamic concerns and join 
points is taken from the “jumping aspects” problem [7]; the object identity problem 
was identified in [10]. 



7.2 Challenge Problems and Reqnirements 

This set of challenge problems is based on variations of a running example involving 
a simple figure editor application (taken from [7]). The editor permits the drawing of 
lines and points, where a line is defined by two points. The application supports 
multiple simultaneous depictions of a figure; each figure element (lines and points) 
can have a different color in each depiction. A sample UML diagram for such a 
figure editor is shown in . 




Fig. 11. UML diagram for figure editor application. 
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Challenge Problem 14: Context Sensitivity to Change Notification 

The figure editor’s user interface is decoupled from the core functionality of the 
application using the Model-View-Controller (MVC) pattern [15], Thus, changes in 
the state of figure elements (position, color, etc.) should trigger an update in the user 
interface. To achieve this update, each method that modifies the state of a figure 
element must send a changed!) message to the FigureEditor, which 
ultimately invokes the user interface’s update mechanism. 

The invocation of the update mechanism is clearly a cross-cutting feature — many 
methods modify figure elements and must send the same changed ( ) messages — 
and, therefore, it should be encapsulated as a separate concern. Notice, however, that 
the movement of a line is handled differently from the movement of a point: the 
line’s moveBy ( ) method will call the moveBy ( ) method of its points, which then 
result in change notification upon the movement of each point in the line. This is 
undesirable, as described in detail in Challenge Problem 5 — the change notification 
should occur only once, after the line has been moved in its entirety. 

This requirement to defer change notification represents the context dependence of 
this aspect: all moveBy ( ) methods represent potential join points for this aspect, but 
the changed ( ) method should not be called (i.e., the notification aspect should not 
be executed) if the moveBy ( ) method was called from another moveBy ( ) method 
(another join point of the same aspect). Thus, this problem illustrates Requirement 9. 

aspect DeferMoves { 

pointcut deferToO: 

! withinall ( FigureElement) & movecall s ( ) ; 

pointcut movecallsO : 

calls(Line, void moveBy(int, int) ) | 

calls (Line, void setPl (Point) ) | 

calls (Line, void setP2 (Point) ) j 

calls(Point, void moveBy (int, int)) | 

calls(Point, void setX(int)) j 

calls (Point, void setY(int)); 

static after!): deferToO { 

System. out .println ( "update ! " ) ; 
fe . changed ( ) ; 

} 

1 



Fig. 13. Aspect! solution to Challenge Problem 14. 

Sample solution: A solution using Aspect! [18] is given in . This figure defines an 
aspect, DeferMoves, which invokes the change notification mechanism by weaving 
an advice after all calls to “movement” methods, but only when the calls to such 
methods are not made from within the FigureElement class. 

Although this solution is almost sufficient to address Challenge Problem 14. it is 
not entirely correct, because it excludes calls to “movement” methods that are made 
from within the FigureElement class itself A correct solution would weave an 
advice after all “movement” methods when the call to the method is not made from 
within any other “movement” method; for example: 
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pointcut deferTo ( ) : 

Iwithinall (movements ( ) ) & movecalls ( ) ; 

In the current version of Aspect!, however, the withinall construct cannot take entire 
pointcuts as arguments. 

Challenge Problem 15: Context Sensitivity in Changing Colors 

The actual drawing of figure elements on the screen is done by calling a draw ( ) 
method on each figure element. The draw ( ) method takes as a parameter a 
Graphics context object, which represents the display on which to draw the figure 
element. 

The context sensitivity issue arises in this problem because each figure element can 
be depicted in a different color on each display. The algorithm for determining the 
color is the same for every draw ( ) method, and it depends on the calling context 
(i.e., on the display from which the draw ( ) method was invoked, directly or 
indirectly). Thus, setting the drawing color is clearly a cross-cutting concern, as the 
draw ( ) methods that this capability affects are scattered across the class definitions 
for all of the figure elements. Again, this is a context-dependent concern, since the 
actual setting of the color depends on the calling context of the join point method. 

Sample solution: 

Fig. 15 shows an Aspect! solution to the changing colors problem. The 
DrawingCanvas aspect encapsulates the canvas (the display on which the drawing 
is depicted) and makes it available to the entire flow of control, starting at the 
invocation of the update ( ) method on the canvas itself Because the invocations of 
the draw ( ) methods occur in that flow of control, the canvas is made available to 
the execution code of the draw ( ) method (i.e., it can access the relevant context 
information). The PerCanvasColor aspect actually introduces the coloring code 
into the draw ( ) method. This aspect wraps code around the draw ( ) methods that 
retrieves the canvas (which is supplied through the getDrawingCanvas ( ) 
method of the DrawingCanvas aspect) and sets the appropriate color. 

Note that while Challenge Problems 14 and 15 both illustrate the need for context- 
sensitive join points, they use the context information differently. In Challenge 
Problem 14, context information is needed to determine whether or not the change- 
notification aspect should be executed at a given join point. In this case, the 
compositor tool uses the context information. In Challenge Problem 15, the aspect 
itself needs the context information instead, to determine the painting color. 

Requirement 20 Context sensitivity may affect a compositor tool or the definition of 
an aspect or a concern. Advanced separation of concerns approaches must provide a 
means of permitting context information to be used by any entity that requires it. This 
includes the ability to identify new context information as the need arises and to 
ensure that it is made available where needed, all encapsulated within a concern that 
can be added to existing code non-invasively. 




234 



Peri Tarr et al. 



aspect DrawingCanvas of eachcflow( cal iToUpdate ( Canvas) ) { 

Canvas c anvas ; 

pointcut callToUpdate (Canvas c) : 

instanceof ( c ) & recept ions ( void update (Graphics )) ; 

before (Canvas c) : callToUpdate (c) 

{ canvas = c; } 

static Canvas getDrawingCanvas ( ) 

{ return (DrawingCanvas . aspectOf ()). canvas ; } 

} 

aspect PerCanvasColor of eachobj ect (instanceof ( FigureElement) ) { 

static Hashtable table = new Hashtable ( ) ; 

Color getColor (Canvas canvas) 

{ return ( Color ) table . get (canvas ) ; } 
static void setColor (FigureElement fe. Canvas canvas. 

Color color) 

{ (PerCanvasColor . aspectOf ( fe) ). table .put (canvas , color); } 

pointcut drawOperations (Graphics g) : 

instanceof (FigureElement ) & receptions (void draw(g)); 

around (Graphics g) returns void: drawOperations (g) { 

Canvas canvas = DrawingCanvas . getDrawingCanvas () ; 

Color color = getColor (canvas) ; 
if ( color == null ) { 

thisJoinPoint . runNext (g) ; 

} 

else { 

Color oldColor = g . getColor () ; 
g. setColor (color) ; 
thisJoinPoint . runNext (g) ; 
g. setColor (oldColor) ; 

} 

} 

} 



Fig. 15. Aspect! solution to the color-changing problem. 



8 Distributed Systems and Middleware 

Group members: Mehmet Aksit, Federico Bergenti, Constantinos Constantinides, 
Pertti Kellomaki, Blay Mireille, Tommi Mikkonen, Klaus Ostermann, John Zinky 

Issues: Quality of service concerns in distributed middleware; collection of data 
about components in distributed middleware (e.g., for monitoring and control of a 
distributed system) 

Categories: Requirements statements 
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8.1 Problem Overview 

Distributed systems pose many challenges for advanced separation of concerns. They 
generally consist of software components and middleware, where the middleware 
provides services for connecting and integrating components in distributed systems. 
Quality of service (QoS) is a key concern in such systems; it includes such critical 
issues as performance and reliability, which impact many (if not all) of the 
components and middleware in a distributed system. 

Motivating papers: Some issues in achieving advanced separation of concerns for 
distributed systems appear in [2] [5] [9]. 



8.2 Challenge Problems and Reqnirements 
Installation of QoS-Aware Middleware 

Installing a distributed system in any given environment may require considerable 
effort to specialize the system for the new context, since different customers of such 
software typically have different QoS requirements that necessitate different 
configurations to achieve. This is particularly true for QoS-aware middleware, where 
multiple general-purpose and QoS-specific components must be deployed and 
instantiated to obtain the desired QoS support. This means that, given a distributed 
application and middleware context, the application, middleware, and QoS 
components must be installed, instantiated, and tuned — a tedious and error-prone task. 

The requirements on QoS-aware middleware suggest a number of research 
challenges for the area of advanced separation of concerns. For example: 

- How should QoS concerns be expressed? 

- How should configurations be expressed? What kinds of concern specification and 
specialization formalisms should be used to keep specialization information 
“untangled” from the rest of a distributed system? 

- What kinds of protocols must be defined between a configuration site and the 
distributed system so that the desired components can be created, installed, and 
tuned? How can this protocol express the required changes to the actual 
configuration after the system is installed? 



Requirement 21 It must be possible to express QoS concerns non-invasively, and to 
specialize them for use in particular (distributed) contexts. 



Requirement 22 It must be possible to express software configurations in terms of 
specializations on existing software, non-invasively. 

Monitoring of QoS-Aware Components 

To ensure that QoS requirements are being satisfied, it is necessary to collect various 
kinds of information from the components — e.g., timing statistics. The kinds of 
information that are needed are context-specific and depend on the particular QoS 
attribute being enforced. For example, in a transaction system, a QoS control system 
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may have to enforce requirements on the number of transactions per second that must 
be able to run. It must, therefore, gather information about the amount of data being 
operated on by transactions, the number of concurrent transactions executing on the 
transaction server, the network contention, and the priorities of transaction requests. 
On the other hand, a QoS control system that is enforcing a different QoS attribute, 
like availability, may require different kinds of information, such as up-time, last read 
and write times, number of users, etc. 



Requirement 23 It must be possible to attach (non-invasively) QoS monitors on 
middleware components. Further, these monitors may be context-specific, which 
suggests that any solution to this requirement must also address Requirement 9. 



Requirement 24 The process to collect data for QoS monitors from across the 
network must satisfy several requirements: 

- The collection process must not create significant overhead. 

- The collection process must operate within stated time constraints. 

- Suitable time-stamp generation techniques must be adopted to overcome the lack 
of a global time. 

- The effect of distance between the information sources (components) and the 
monitoring points must be taken into account in processing the data. 

An example of this requirement is an on-line banking application, where the bank 
must offer mortgages within a given period of time. This process is realized through 
the interactions among multiple services that may reside in different locations. A 
QoS monitor must, therefore, gather information from different locations to permit the 
monitoring and control of mortgage offers. 

Adaptation of Middleware 

In a dynamically changing application context, and in case of multiple, distributed 
and sometimes conflicting executions, it may not be possible to fix the 
implementation of a service for a given QoS specification. In this case, the service 
may try to provide best effort to achieve the specified QoS specification. 

For example, a transaction system may provide a fixed set of services such as 
begin, end and abort transaction. There are, however, many possible implementations 
of a transaction service, and each implementation may perform differently from 
others in different contexts. Similarly, it may be desired to select the implementation 
of a transport protocol among various alternatives based on the characteristics of the 
data to be transferred. 

This observation implies Requirement 9, and it also imposes the following new 
requirement: 



Requirement 25 It must be possible to dynamically adapt {non-invasively) the 
implementation of a middleware system so that the system provides the best effort 
within the context of agreed-upon QoS constraints. 




Workshop on Aspects and Dimensions of Concern 



237 



9 Conclusions and Future Work 

This workshop identified fifteen challenge problems and twenty-five requirements on 
advanced separation of concerns approaches. These problems and requirements are in 
need of further exploration and validation, and they are only a small subset of those 
that must ultimately be produced. Nonetheless, they represent a significant first step 
in defining boundaries of the emerging area of advanced separation of concerns, and 
in defining constraints on solution approaches. 

It is our hope that researchers and technology providers will take these challenge 
problems and requirements in several directions: 

- Improvement of, and new directions for, existing approaches '. These challenge 
problems and requirements should be used to identify limitations in, and growth 
areas for, existing approaches to advanced separation of concerns. They may also 
help solution-providers to identify tradeoffs that they had to make in defining their 
approaches and to consider the overall impact of those tradeoffs. 

- Generation of new approaches : While a number of advanced separation of 

concerns approaches already exist (e.g., compositors, logic meta-programming, 
etc.), these problems and requirements may help to suggest new approaches and 
technologies that help developers to use advanced separation of concerns more 
effectively throughout the software lifecycle. 

- Comparative analysis of approaches '. To date, there has been no consistent, 
comprehensive means of comparing different approaches and technologies. We 
hope that these problems and requirements provide a way for researchers and 
developers to classify their own approaches, and to compare and contrast them 
with other approaches. Towards this goal, we strongly urge technology providers 
to produce solutions to the challenge problems using their technologies, and to 
make those solutions available to the community. 

- Evolution of these problems and issues, and identification of new ones : As noted 
earlier, a single, two-day workshop is not sufficient time to produce a complete set 
of requirements, issues, or challenge problems, or even to produce a representative 
set. The results reported in this document are preliminary. Further work will be 
required to identify incompleteness, inconsistencies, and other errors. 

Above all else, it is our hope that these results will be discussed, revised and 
expanded by the advanced separation of concerns community, and that the 
community will identify new problems and issues in the future. We look forward to 
the individual research efforts, and to the successors of this inspiring workshop, that 
will so. 
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Background 

The ECOOP workshop on Mobile Object Systems was first organized in 1995 
and has been held every year since. The first two episodes in the series - en- 
titled “Objects and Agents” (1995) and “Agents on the Move” (1996) - were 
exploratory in nature, reflecting a growing awareness and interest in the possibil- 
ities of mobile code and mobile objects for Internet programming. Towards the 
end of the 1990s, Interest in the domain began to stabilize and several mobile 
object systems appeared in the research community. As a consequence, further 
editions of the Mobile Object Systems workshop concentrated on specific aspects 
of mobile objects. Thus, the title of the 1997 workshop was “Operating System 
Support”, the theme of the 1998 workshop was “Security”, and the theme of the 
1999 installment was “Programming Language Support”. 

With the workshop series entering its second half-decade, one of our goals for 
the 2000 workshop was to see if the enthusiasm for the mobile object paradigm 
that reigned during the initial workshop years was still there. To that end, we 
decided that the theme of this years workshop should unite researchers and 
developers from all sections of the mobile object community. We decided on the 
title “Operating System Support, Security and Programming Languages”, thus 
uniting the three themes of the preceding years. A session was held for each of 
these themes. We also stressed in the Call For Papers that we were particularly 
interested in papers that describe mobile object application developments and 
experience reports, since we wanted to see if the initial promises of the domain 
were being fulfilled. 

We were very happy when we received 26 submissions for the workshop, a 
record number. Unfortunately, we could only accept 13 of these, given that only 
one day had been allocated for the workshop. 

For the program committee, we chose experts from all areas of the mobile ob- 
ject systems domain, many of whom had already participated in previous editions 
of the workshop in some form. The program committee was: Bob Gray (Dart- 
mouth College, USA), Eric Jul (CopenHagen University, Denmark), Doug Lea 
(OSWEGO, USA), Jochen Liedtke (Karlsruhe University, Germany), Manuel 
Serrano (Nice University, France), Peter Sewell (Cambridge University, UK), Jan 
Vitek (Purdue University, USA), and Jarle Hulaas (Geneva University, Switzer- 
land). We are very grateful to these researchers for reviewing papers, and for 
contributing to the workshop over the years. 



J. Malenfant, S. Moisan, A. Moreira (Eds.): ECOOP 2000 Workshops, LNCS 1964, pp. 241- 125^ 2000. 
(c) Springer- Verlag Berlin Heidelberg 2000 
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The workshop was held on Tuesday, June 13th - a day prior to the ECOOP 
conference - at the site of INRIA {Institut National pour la Recherche en In- 
formatique et Automatique) at Sophia Antipolis. There were over 50 attendees, 
which is another record for the workshop. We decided on a format of 15 minute 
talks followed by 15 minutes of discussion for each talk. 

The Talks 

The workshop was divided into three sessions: agent systems, operating system 
support and security, in accordance with its principal themes. We now give an 
extended abstract of each talk ~ written by the authors - before summarizing 
the main elements of discussion. 



Agent Systems 

The first talk was about the NOMADS system and was given by Niranjan 
Suri. NOMADS is a mobile agent system that supports strong mobility (i.e., the 
ability to capture and transfer the full execution state of mobile agents) and safe 
Java agent execution (i.e., the ability to control resources consumed by agents, 
facilitating guarantees of quality of service while protecting against denial of 
service attacks). The NOMADS environment is composed of two parts: an agent 
execution environment called Oasis and a new Java compatible Virtual Machine 
(VM) called the Aroma. The combination of Oasis and the Aroma VM provides 
two key enhancements over today’s Java agent environments: 

1. The ability to capture and transfer the full execution state of mobile agents 
(strong mobility). This allows agents to be moved ’’anytime” at the demand 
of the server or the agent rather than just at specific pre-determined points. 

2. The ability to control the resources consumed by agents thereby facilitat- 
ing guarantees of quality of service while protecting against denial of service 
attacks (safe execution) . Adding these resource control capabilities to the ac- 
cess control mechanisms already provided by the new Java 2 security model 
allows mobile agents to be deployed with greater confidence in open envi- 
ronments. 

Strong mobility is vital for situations in which there are long-running or 
long-lived agents and, for reasons external to the agents, they need to suddenly 
move or be moved from one host to another. In principle, such a transparent 
mechanism would allow the agents to continue running without any loss of their 
ongoing computation and, depending on circumstances, the agents need not even 
be aware of the fact that they have been moved (e.g., in forced mobility situ- 
ations). Such an approach will be useful in building distributed systems with 
complex load balancing requirements. The same mechanism could also be used 
to replicate agents without their explicit knowledge. This would allow the sup- 
port system to replicate agents and execute them on different hosts for safety, 
redundancy, performance, or other reasons. 
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The Aroma VM supports capturing the execution state of one or more threads 
executing inside the VM. The state capture mechanism is fine-grained and allows 
state to be captured between any two Java bytecode instructions. The captured 
execution state information is platform-independent thereby allowing NOMADS 
to move processes across different architectures. 

Mechanisms for monitoring and controlling agent use of host resources are 
important for three reasons. First, it is essential that access to critical host re- 
sources such as the hard disk be denied to unauthorized agents. Second, the use 
of resources to which access has been granted must be kept within reasonable 
bounds, making it easier to provide a specific quality-of-service for each agent. 
Denial-of-service conditions resulting from a poorly-programmed or malicious 
agent’s overuse of critical resources are impossible to detect and interrupt with- 
out monitoring and control mechanisms for individual agents. Third, tracking of 
resource usage enables accounting and billing mechanisms that hosts may use to 
calculate charges for resident agents. 

NOMADS supports two kinds of resource limits: rate and quantity. Rate 
limits include controls over disk and network read and write rates (expressed 
as bytes/millisecond) and also over CPU. Quantity limits include controls over 
disk space and total number of bytes read or written to disk or network. The 
resource limits are also fine-grained and dynamically adjustable. 

The next talk was Agent Mobility and Reification of Computational 
State, given by Werner Van Belle and Theo d’Hondt of Vrije University in 
Brussels. The paper describes an experiment with mobility in multi-agent sys- 
tems. The setting is a machine that supports reification of the computational 
state of a running process. The objective is to investigate how this feature facil- 
itates telescripting and to speculate on how languages like Java should evolve to 
include the resulting notion of strong migration. 

The next talk was given by Prof. Kazuhiko Kato on a Mobile Object 
Substrate for an agent system. Computer systems are in general hierarchi- 
cally structured; typical layers are hardware, operating system, programming 
language, and application. In which layer should object mobility be supported? 
A typical approach, which is adopted in most current mobile object systems, 
is to provide support in the programming language layer. In this paper the au- 
thors discuss another approach to incorporating object mobility in mobile object 
systems; that is, incorporating object mobility in a substrate below the program- 
ming language layer. The discussion is based on experience, over the past several 
years, of developing a mobile object substrate named Planet. 

One advantage of providing basic object mobility support in the middleware 
layer is that the same mobility concept can be incorporated into many program- 
ming languages, as well as in application software. The middleware may thus 
become a substrate on which to build mobile object systems with a shared im- 
plementation and a single site for for improved performance. Another advantage 
is that support for object mobility functions in this layer can be more portable 
than support in an operating system kernel and can run on several operating 
systems. 
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Planet provides three sets of functions for dealing with mobile objects to the 
underlying operating system: mobile memory segments, object repository, and 
safe API execution. Planet assumes that an object may include three segments, 
a program code segment, a data segment, and a computation state (the so-called 
thread) segment. It supports the dynamic loading of these segments to any free 
area in the virtual address space of a user process. Planet’s loading mechanism is 
a remote memory-mapped file mechanism, a network-wide extension of the local 
memory-mapped file mechanism which is supported by many modern operating 
systems. For safe execution of objects by the client process. Planet provides 
a safe API execution mechanism. Planet considers each virtual address space 
as a “sandbox.” Objects loaded to a virtual address space directly access each 
other. Planet inhibits a user process from issuing system calls directly to the 
operating system kernel; instead, it only allows the use of predetermined API 
calls to manipulate resources which are managed by the operating system. This 
is controlled by a safety policy checker. The safety policy checker is a user-level 
process, and one safety policy checker is associated with each user process into 
which mobile objects are loaded. 

Currently Planet takes up 40,000 lines of C code and about a hundred lines of 
assembler code. It currently runs under Solaris on SPARC and Intel x86 CPUs, 
and under Linux on Intel x86 CPUs. 

By using the Planet, the authors implemented heterogeneous object mobility, 
mobile programming languages based on C, C-I--I-, and Tcl, and a mobile Web- 
search robot system. 

Then we had Thomas Geswind of the Technical University of Vienna who 
compared some Object-Oriented Mobile Agent Systems. Mobile agents are 
a new paradigm for distributed applications and an increasing number of mobile 
agent platforms emerged recently. Unfortunately, most of these systems are nei- 
ther compatible to existing standards nor among each other. The author have 
compared three prominent industry platforms and promising research systems 
regarding their object oriented design and component model. 

Depending on the system’s focus, the author distinguish between ’’typed” 
and ’’untyped” agent systems. Typed agent systems require the agents to be a 
sub-type of a given agent-class/interface. Typically, the agent’s type provides a 
callback method that is called to revive an agent after it has been moved to a 
different location. Untyped agent systems allow any object to be regarded as an 
agent. While this approach may be more flexible, it provides also some hazards, 
as an object not intended to be moved might be moved accidentally. After moving 
to a new location, the agent is typically revived using Java’s reflection API as 
there is no well-known callback method available via Java’s type system. 

Based on this comparison, one was able to develop an abstraction layer that 
allows a mobile agent to be transferred between different agent systems. However, 
due to the difference in the agent systems’ object models and transfer protocol, it 
is not possible to let an agent written for system ” foo” to be transfered to system 
’’bar”, as this would require to integrate all functionality of ”foo” into ’’bar” 
including ”foo”’s agent-model. The author chose to add an abstraction layer on 
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top of the existing systems and to let the agent interact with the abstraction 
layer. This allows an agent written for the abstraction layer to migrate between 
different agent systems. The abstraction layer translates the agent’s requests into 
the calls of the underlying agent system and vice versa. 

Based on the comparison and the implementation of the abstraction layer the 
paper derives two key issues. While typed agent systems focus on the provision 
of a ’’traditional” agent system, untyped agent systems maintain a broader focus 
on mobile objects and mobile code in general. Based on the abstraction layer, we 
can identify that a different object model cannot be integrated seamlessly into 
existing agent systems. This requires more support from the agent system. We 
suggest to implement the functionality of migrating an agent from one system 
to another like any other service provided by the agent system and to provide 
support for additional migration modules that are able to accommodate different 
agent models. 

Finally, just before the break, Dominic Duggan of Stevens Institute of 
Technology presented some Abstractions for Fault- Tolerant Wide Area 
Network Programming Languages. Wide-area computation is a recent area 
of research, concerned with developing abstractions for programming the Inter- 
net. The motivation is that programming the Internet is very different from pro- 
gramming over local area networks, in terms of latency, bandwidth and security. 
Abstractions need to be provided to the programmer that expose the network, a 
fundamental difference from LAN programming where RPC and RMI attempt 
to make the network transparent. Security has been a particular concern of 
wide-area computation because of the realization that the Internet is evolving 
from a flat address space to a more complicated address space, partitioned into 
administrative domains by firewalls (both physical and virtual). 

The organizing principle for recent work has been mobile computation, al- 
lowing code or processes to be transported across the network. This work lays 
the foundations for designing and implementing programming languages, where 
it is possible to reason formally about security properties in those languages. 
Although fault tolerance has long been a concern of work in LAN programming 
languages, this has received relatively little attention in the held of wide-area 
computation. 

This paper provides an informal tutorial review of some of the key develop- 
ments in wide-area computation, in particular the pi-calculus and the ambient 
calculus. The paper then considers the ATF Calculus, a kernel language for 
wide-area network programming with atomic failure as its organizing principle. 
Atomic failure is captured by the abstraction of transactions. This abstraction is 
closely related to the notion of transactions from databases and LAN program- 
ming, but with significant differences, for example, with correctness based on 
causal consistency rather than serializibility. The ATF Calculus combines atomic 
failures with various mechanisms for secure programming that have been pro- 
posed for wide-are languages. The calculus has both a type system and a formal 
operational semantics. Work is continuing on refining the security mechanisms 
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underlying the calculus, addressing issues in fault tolerance over the Internet 
that do not arise when programming over LANs. 

Operating System Techniques 

The first talk after the lunch break was given by Alessio Vecchio of Pisa 
University on MobileRMI. The benefits introduced by the use of mobile code 
and mobile objects have been highlighted in numerous research works, but their 
adoption in real-world applications is still missing. The authors argue that the 
lack of integration between the language support for mobility and the usual 
programming environment, can reduce the advantages and limit the diffusion of 
such design paradigms. The programmer should have at his/her disposal a set 
of primitives for object and code mobility, useful to face the particular problem 
using the most appropriate mobile code design paradigm, such as remote evalua- 
tion (REV), code on demand (COD), or mobile agent (MA). Also, it is desirable 
to have such primitives integrated, or even better embedded, in a familiar pro- 
gramming language, in order to avoid changing the programmer’s way to code 
when mobility is not used or when it is used in minimal part. 

The authors try to contribute to bridge this gap by proposing MobileRMI, 
a toolkit that enhances the UnicastRemoteObject class of Java RMI by adding 
methods for creating objects in a remote address space, as well as for moving 
them from an address space to another. By means of such primitives, the pro- 
grammer can easily implement all different paradigms based on code mobility 
(REV, COD, and MA). 

The mobile remote object abstraction is implemented by the MobileUnicas- 
tRemoteObject (MURO) class of MobileRMI. With the MobileRMI add-ons, a 
client application, besides obtaining the reference to an existing MURO the same 
way it can do with a standard UnicastRemoteObject (e.g.: using the RMI nam- 
ing facility), can also create a MURO in a different address space by means of the 
create() method, which returns the remote reference to the object. In addition, 
each client application that owns a reference to a MURO (including the MURO 
itself) can trigger its migration to another address space by invoking a move() 
method on the object reference. Despite of object migration, all client applica- 
tions that hold references to a mobile remote object remain able to interact with 
it by means of method invocation. The client which invokes the move() gets its 
reference automatically updated, while a dummy-object replaces the migrated 
MURO on the departure site in order to carry out method invocations coming 
from clients which still own old references. If the MURO moves several times, a 
chain of dummy-objects allows to reach it. The dummy-object handles method 
invocations coming from clients by raising the ObjectMovedException. On re- 
ceiving the exception, the client may decide to invoke the getNewLocation() 
method in order to update the remote reference. This mechanisms guarantee 
that a link exists between each client and the migrated object. When no clients 
refer a given dummy-object, either because they have updated their references 
to the new location of the MURO, or because they have been terminated, the 
dummy-object becomes eligible for garbage collection. 
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The toolkit has been implemented by replacing some RMI internal classes, 
but without modifying the Java interpreter in order to preserve programs and 
toolkit portability. When compiling or executing applications using the mobile 
remote object abstraction it is only required to put the MobileRMI package in 
the classpath. 

Walter Binder then talked about JSeal. Recently, many research projects 
have stressed the benefits of mobile agent technology for large-scale Internet 
applications, such as the reduction of network traffic, the support for off-line 
operation, simplified load balancing, as well as improved scalability and fault 
tolerance. For the success of a mobile agent platform, a sound security model, 
portability, and high performance are crucial. Since mobile code may be abused 
for security attacks, mobile agent platforms must protect the host from malicious 
agents, as well as each agent from any other agent in the system. In order 
to support large-scale applications, mobile agent systems have to be portable 
and to offer good scalability and performance. However, current mobile agent 
platforms fail to provide sufficiently strong security models, are limited to a 
particular hardware architecture and operating system, or cause high overhead. 
As a result, commercial applications based on mobile agent technology are not 
in widespread use today. 

In contrast to popular mobile agent platforms, the design and implementa- 
tion of the J-SEAL2 mobile agent system reconcile strong security mechanisms 
with portability and high performance. J-SEAL2 is a micro-kernel design im- 
plemented in pure Java; it runs on every Java 2 implementation. Considering 
the variety of hardware used for Internet computing, it is crucial that J-SEAL2 
supports as many different hardware platforms and operating systems as possi- 
ble. For this reason, J-SEAL2 does not rely on native code nor on modifications 
to the Java Virtual Machine. The J-SEAL2 kernel fulfills the same role as a 
traditional operating system kernel: It ensures protection of different agents and 
system components, provides secure communication facilities, enforces safe do- 
main termination with immediate resource reclamation, and controls resource 
allocation. 

The J-SEAL2 kernel offers strong protection domains allowing to isolate 
agents and system components from each other. The kernel acts as a reference 
monitor ensuring that there is no direct sharing of object references with distinct 
domains. Thus, J-SEAL2 guarantees accountability, i.e., every object belongs to 
exactly one protection domain. This feature eases memory accounting and pro- 
tection domain termination. J-SEAL2 protection domains are multithreaded and 
organized in a tree hierarchy. The micro-kernel ensures that a parent domain may 
terminate its children at any time. As a consequence, all threads in the child do- 
main are stopped and all memory resources used by the child domain become 
eligible for garbage collection immediately. 

The J-SEAL2 kernel offers two different communication facilities, channels 
and external references. In both cases, messages are passed by deep copy. In that 
way, the kernel prevents direct sharing of object references between different 
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protection domains. This property is crucial for protection domain isolation, as 
aliasing between different domains would undermine protection. 

Channels support communication only between direct neighbors in the hier- 
archy. If two neighbor domains issue matching send and receive communication 
offers, the kernel passes the message from the sender to the receiver. With the 
aid of channel communication, it is possible to achieve complete mediation. This 
means that it is possible to intercept all messages going in and out of an agent. 
However, channel communication becomes a significant performance bottleneck, 
if messages must be routed through a series of protection domains, since commu- 
nication involves thread switches proportional to the communication partners’ 
distance in the hierarchy. 

External references are an optimization, they support indirect sharing of ob- 
jects between distinct protection domains that are not necessarily neighbors. 
Thus, external references enable efficient communication shortcuts in deep hier- 
archies. An external reference acts as a capability to invoke methods on a shared 
object. When an external reference is passed to another domain, the receiver 
gets a copy of the communicated external reference. The sender may invalidate 
that copy at any time with immediate effect. 

The workshop article provides a detailed description of the design of the J- 
SEAL2 micro-kernel and explains some techniques enabling the implementation 
of strong protection domains efficiently in pure Java. 

Tim Coninx then gave a talk On the Use of Threads in Mobile Object 
Systems. In this paper, the authors introduce distributed tasks, which serve to 
maintain JVM thread semantics in mobile object systems. 

A distributed task defines a global thread identifier for a thread trace that 
crosses host boundaries in a distributed system. Such a thread trace corresponds 
to a sequence of method calls where at least one is a remote method invocation. 
As such, a distributed task unites a set of different JVM thread stacks that are 
distributed among different hosts. 

An important topic of current research is the use of locks with synchronized 
methods and wait/notify methods. Suppose a thread wishes to enter an already 
locked method, then the JVM will only grant access if this thread owns the lock. 
With a distributed task, it may well be possible that the same distributed task is 
trying to re-enter the method by means of a different thread. In this case, access 
is denied by the JVM. The authors investigate how concept of distributed locks 
can help to prevent this from happening. 

In mobile object systems, the problem of distributed tasks aggravates. When 
migration makes two objects sharing a thread trace become non-local, this thread 
trace must be dynamically transformed into a distributed task. After the migra- 
tion, it is necessary the thread trace is split up in two different threads-tacks 
that make up the resulting distributed task. 

In order to support distributed tasks, we first need a mechanism to capture 
and reestablish the state of Java threads. This functionality is currently not 
provided by standard Java technology. The authors have implemented a trans- 
parent thread migration mechanism (for reference, see URL above) by extracting 
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the state of a running thread from the application code that is running in that 
thread. To achieve this, they developed a byte code transformer that instruments 
the application code by inserting code blocks that do the actual capturing and 
reestablishing of the current thread’s state. The mechanism is fully implemented 
at the code level, without modifying the Java virtual machine. 

The last talk of this session was given by Tom Walsh on the subject of 
thread migration over Internet sites. An executing thread, in an object oriented 
programming language, is spawned, directly or indirectly, by a main process. 
This in turn gets its instructions from a primary class. In Java there is no close 
coupling of a thread and the objects from which they were created. A container 
abstraction is taken to be that which combines threads and associated objects 
together into a logical succinct unit. A container that holds threads and objects 
whose variables are all housed within the same container is a perfect candidate 
for strong migration. However, other threads may address resources external to 
its home container. If these external resources are of a generic type they should be 
replaceable by identical resources on any potential destination site. To achieve 
this we propose a combination of three techniques to allow the containers to 
migrate in a manner that approaches the strong mobility paradigm yet does not 
resort to retaining bindings to resources across distant and unreliable networks. 

Stack Collapse: Java serialization does not allow the thread stack to be cap- 
tured. Therefore, it may prove prudent to try to collapse the stack naturally. If 
no methods are being executed when migration is initiated then the stack will 
be flat (no local variables or environment variables to be saved), thus allowing 
the object to be moved and restarted on a new node. Essentially the object is 
being placed in a hibernation state. The main() method will be the sole remain- 
ing frame. The remains of the object’s state can be encapsulated in the instance 
variables. Java’s serialization can capture these variables automatically. How- 
ever, just like threads, not all variables are serialisable. Some objects are not 
capable of being migrated. Instead, providing alternatives to these resources on 
the destination host can provide a mechanism that aims to reduce the depen- 
dency on retaining references across the Internet. This is generally referred to as 
data space management. 

Data Space Management: As mentioned previously objects and threads may 
reference resources external to their home container. In many instances the re- 
sources accessed are of a generic nature as the primary purpose of a container 
is to group all essential elements into a single migrating unit. Host systems can 
provide generic resources that migrating containers can access. Examples include 
display screens for reporting progress, printers, proxy servers, classloaders, repli- 
cated databases and object request brokers. The underlying system provides this 
service automatically. Thus, the container further severs its ties with the original 
host. The Internet is an unreliable network that penalizes programs attempting 
to use it in the same manner as a quick, reliable LAN. Using local equivalents 
allow the container to migrate and continue executing using identical services. 
The effect of this is to reduce the dependency the object has on potentially 
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unreliable remote resources. The objective is to only retain bindings to remote 
resources when they are either essential or desirable. 

Strong Mobility in Java: A Java thread can be created from class methods 
but it then becomes a separate abstract entity in the virtual machine. The state 
of the object is retained separately on the heap. Executing threads hold all local 
variables generated in working memory. The standard Java API does not provide 
mechanisms to realize strong migration. There is no way to access these thread 
objects directly. The authors investigate whether this is feasible using JavaSoft’s 
Just In Time (JIT) Compiler API. This API gives hooks into the virtual machine 
that can be used, amongst other things, to extract the execution environment for 
particular threads. Documentation on the JIT API is limited therefore extension 
of the Java Runtime Environment can not be ruled out. 

A single Java stack frame is comprised of three parts. The operand stack, 
the execution environment and the local variable array. The operand stack is a 
32-bit LILO data structure where values are pushed onto and popped off during 
expression evaluations. The Frame Data Structure (or execution environment) 
stores the Virtual Machine’s registers and program counters. The Local Variable 
Array serves (among other functions) as a store for method parameters and local 
variables Since the values on the stack are essentially just ordered collections of 
numbers it is necessary to build a parallel type stack which allows us to make 
sense of the values and their meaning. The JIT hooks allow the stack frame of 
specific threads to be examined and saved. They also give access to the Virtual 
Machine functions for memory allocation and deallocation. This forms the main 
basis for this part of the migration process. 

Analyzing a thread’s stack allows the system to ascertain which, if any, re- 
sources being using are outside its container. A thread whose stack scan reveals 
no references outside its container can be suspended. Threads with references 
to outside resources have their references nullified and then bound to a new 
equivalent resources as described in the previous section. The entire frame is 
then saved, transmitted and re-seeded in a new Virtual machine where it can 
continue execution from its original checkpoint. 



Security 

The security session was opened by a talk by Frank Piessens, Bart Van 
Haute, Erik van Hoeymissen, Gregory Neven from Leuven, Belgium on 
the Tradeoff Between Communication and Trust in Secure Computa- 
tions. In this paper, the authors show that mobile code technology may prove 
to be a useful tool in advanced cryptographic protocols for secure distributed 
computing. 

Secure distributed computing (SDC) addresses the problem of distributed 
computing where some of the algorithms and data that are used in the compu- 
tation must remain private. Usually, the problem is stated as follows, empha- 
sizing privacy of data. Let / be a publicly known function taking n inputs, and 
suppose there are n parties (named pi] i = each holding one private in- 

put Xi- The n parties want to compute the value f{xi; ...;Xn) without leaking 
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any information about their private inputs to the other parties. An example is 
voting: the function / is addition, and the private inputs represent yes (xi = 1) 
or no {xi = 0) votes. It is possible to keep an algorithm secret, instead of data, 
by making / an interpreter for some programming language and by setting Xi 
to the encoding of the algorithm. 

SDC is trivial in the presence of a globally trusted third party (TTP). All 
participants send their data and code to the TTP (over a secure channel), the 
TTP performs the computation and broadcasts the results. The main drawback 
of this approach is the large amount of trust needed in the TTP : all participants 
must agree on one single TTP of which they unconditionally trust the code 
and the execution platform on which it is running. However, solutions without 
a TTP are also possible. Over the past two decades, a fairly large variety of 
cryptographic solutions has been proposed. In these solutions, the trust require- 
ments are minimal: every participant trusts his own execution site and expects 
that the other participants provide correct values for their own inputs. The main 
drawback of these solutions is that the communication overhead is far too high 
to be practically useful in a general networked environment. 

In this paper the authors show how the use of semi-trusted hosts and mo- 
bile agents employing these cryptographic techniques can provide for a trade-off 
between communication overhead and trust. The communication overhead is 
alleviated if the communicating parties are brought close together. In the ap- 
proach, every participant sends its representative agent to a trusted execution 
site. The agent contains a copy of the private data Xi and is capable of running 
a SDC-protocol. Different participants may send their agents to different sites as 
long as they are located closely to each other. Of course, a mobile agent needs to 
trust his execution platform. However, not all the participants have to endorse 
the same site and the trusted sites are not involved directly. They simply offer 
a secure execution platform and don’t have to know the protocol used between 
the agents. In other words, the trusted execution sites are generic and can be 
used for a wide variety of applications in a uniform way. 

The next talk was Mobile Code Protection with Smartcards, given 
by Serge Loureiro of Eurocom, France. With the advent of new computing 
paradigms like mobile code and ubiquitous computing, the privacy and integrity 
of software programs become a major concern beyond classical data security con- 
siderations. Security with mobile code has long been viewed only as the problem 
of protecting local resources against potential misuse and denial of service by 
the mobile code. This problem received much attention from software manufac- 
turers as well as researchers, resulting in various solutions included in recent 
releases of products like JAVA. Conversely, research on mobile code protection 
against potential attacks from the runtime environment could not come up with 
practical solutions yet, hence the limited if non-existing coverage of the problem 
by the industry. Assuring mobile code’s security in an untrusted execution en- 
vironment without tamper proof hardware has been conjectured as impossible 
in the literature; some solutions based on cryptography were recently published, 
but unfortunately the results were not suitable for practical applications. 
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This paper presents a solution for the integrity and privacy of mobile code 
execution. Privacy of execution aims at preventing the disclosure of a program’s 
semantics during its execution in a potentially hostile runtime environment. In- 
tegrity of execution assures that a program executed in a potentially hostile 
environment actually complies with its original semantics. A solution for assur- 
ing the integrity of execution may consist of verifying that the results of an 
execution on a potentially hostile environment actually belong to the set of pos- 
sible results of the original mobile program. The suggested solution requires a 
trusted hardware with limited capacity like a smartcard and assures the security 
of a program executed on untrusted runtime environments by means of some 
interactions between the program and the trusted hardware. Unlike prior solu- 
tions, the proposed technique allows multi-step execution and the delivery of 
cleartext output at the remote site. 

The talk by Anand Tripathi was about the Delegation of Privileges 
to Mobile Agents in Ajanta. Ajanta is a Java-based system designed to 
support secure execution of mobile agent-based distributed applications in open 
networks. This paper presents the mechanisms that the authors have developed 
for the Ajanta system to allow an agent’s owner to delegate privileges to its agents 
and impose any desired restrictions on their capabilities when they execute at 
remote hosts. For example, in an e-commerce application a user may wish to 
allow its agent to only bid or negotiate for the prices for certain products at a 
server but not to perform any purchase. Thus an agent’s owner could be held 
responsible only for the actions authorized by him. A server can interpret and 
enforce these privileges and restrictions according to its own security policies. 
Also, sometimes a server may need to forward a visiting agent to another server 
to request certain additional services that may be needed to complete the tasks 
requested by the agent. In such a situation, the forwarding server may need 
to grant additional privileges to the agent or restrict some of its capabilities. 
The problem of delegation of privileges has remained largely unaddressed by the 
research community. The mechanisms presented here address these needs. 

Every agent carries a tamper-proof certificate, called credentials, assigned to 
it by its creator. This contains the agent’s name, and the names of its owner 
and creator. It is signed by the agent’s owner. In this design the privileges and 
restrictions are associated with the agent’s credentials in a tamper-proof manner. 
For this, the credentials object includes the hash values of the objects defining 
privileges and restrictions. Any tampering of the objects containing the privileges 
and the restrictions can be detected. 

The privileges for an agent can specify the servers it is allowed to visit, 
the resources it should be allowed to access at a server (these include system 
resources such as file and network ports) , the specific operations that it is allowed 
to invoke on a resource, and limits on the time for which it can be resident at 
a server. The restrictions could specify the hosts that the agent should never 
visit, or the names of the resources/services that should never be allowed to be 
accessed by the agent when executing at some given server. 
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Sometimes a server may need to forward an agent to another server, which 
may not be on the agent’s original travel plan prescribed by its creator. This 
kind of situation arises when a server needs to obtain certain services from an- 
other server in order for the agent to complete its designated task. In such a case 
the second server would perform the requested service under the authorization 
given by the forwarding server. The forwarding server prepares a ticket contain- 
ing server’s specifications of additional privileges and restrictions for the agent. 
Using these privileges, the agent can request services on behalf of the forwarding 
server. This ticket contains the agent name, server name, hash values of server’s 
delegated privileges and restrictions, and the agent owner’s signature on the cre- 
dentials object. The server then signs this ticket. This ticket is thus associated 
with the agent whose name and credentials signature are included in the ticket. 
This paper describes how Any tampering of the ticket can be detected. 

When an agent is transferred to a server, a separate protection domain is 
created for it by the server. The server maintains information for an agent, 
its credentials and ticket objects together with privileges and restrictions. Each 
server has an access control list defining its own security policies. A server en- 
forces an agent’s privileges and restrictions in the context of its own security 
policies, which are always considered to be dominant. All security sensitive op- 
erations involving system resources, such as files and network connections, result 
in a call to the security manager object of the server. The security manager de- 
termines if access is to permitted. If allowed by the server, it further checks the 
agent’s privileges and restrictions stored in its domain database entry. 

The final talk of the workshop was given by Volker Roth of the Frauenhoefer 
Institute in Germany. Early research on mobile agent systems concentrated on 
how to migrate mobile agents. Manifold agent systems exist today and there is a 
notable shift towards research in how to best support transparent communication 
between mobile agents. Transparent means that agents need not be aware of the 
actual location of agents with which they wish to communicate. Two problems 
must be solved in order to achieve transparent communication: 

— The peer agent must be located, for instance by means of a name service 
that maps an agent’s location invariant name onto its current whereabouts. 

— Messages must be routed to the peer. This can become difficult since mobile 
agents might “run away” from messages. 

In this article, the authors address the problem of how to locate agents. The 
goal is to provide adequate global name services for mobile agents, which scale 
to the Internet and account for the particularities of mobile agents (frequent 
changes in locations), as well as for security issues. Name services are both 
targets of potential attacks on the mobile agent infrastructure as well as possible 
source of attacks on the privacy of mobile agent owners. Some attacks we discuss 
apply to name services in general. However, the requirements to be fulfilled by 
name services for mobile agents and the defensive strategies have to account for 
mobility of agents. 

At the center of the approach is the computation of implicit agent names 
based on the static part of a mobile agent, and the use of random cookies as a 
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means of authenticating location updates. The cookies are passed with a migrat- 
ing agent, and serve the agent’s destination as proof of permission for updating 
that agent’s location entry in the name server. Scalability is addressed by split- 
ting responsibility among name servers based on a prefix of the implicit agent 
names. 

The protocol yields improved protection against attacks on the privacy of 
agent owners. Furthermore it is efficient and easy to implement, and agents 
cannot claim a fake identity. 

Conclusions 

The consensus at the end of the workshop was that the mobile object systems 
domain is alive and well, and people will continue researching the domain for 
another few years at least. There was some concern expressed however that 
few applications have been developed by the community that exploited mobile 
objects. 

One of the main questions discussed was what precisely the goal of object 
mobility is. Some systems presented were designed to support transparent object 
migration over a local area network - the goal principally being to support load 
balancing. Some participants questioned the utility of this, arguing that the main 
interest of mobile agents is for Internet programming. Migration over local area 
networks was studied in the 1980s with systems like Emerald. Many felt that 
mobile objects are best suited to wide area networks, or the Internet, where they 
can be used to overcome the handicap of latency. Migration over the Internet is a 
different situation to migration over local area networks because it is difficult to 
enable objects to transparently move: Environments are heterogeneous in terms 
of security policies, as well as available libraries and services, etc. so executions 
of objects on different sites cannot be expected to behave similarly. 

There was general surprise at the number of papers that treated thread 
mobility, after an apparent quell in this topic over the past few years. There 
were interesting propositions on how thread mobility in Java could be achieved, 
though it is recognized as a difficult topic. 

Most of the mobile object systems described were based on Java. The reason 
for this is mostly pragmatic - Java has achieved a good deal of momentum over 
the past few years - though it is recognized that there are still many problems 
to be solved around Java, e.g., thread mobility. 

Some participants pointed out that program mobility - or “executable con- 
tent” - is now ubiquitous on the Internet, in the form of applets, scripts etc. 
There is a sentiment that the mobile object systems community was being over- 
taken by events with regard to executable content, since many issues relevant 
to executable content on the Internet are still poorly treated by the community, 
e.g., secure code isolation, handling denial of service attacks, code management, 
etc. 

The general feeling at the end of a long day was that the workshop had been 
productive, and that the workshop series should be continued until next year 
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at least. We then had a unique occasion to continue on workshop topic at the 
conference, as Ralf Meika from Eurocom in Sophia Antopolis organized a panel 
discussion on Mobile Agents, Security and Electronic Commerce. A summary of 
this panel is also available in this volume. 

We should lastly mention that all papers and presentations of this year’s 
workshop and of all previous editions are available at our website: 

http : / / cui . unige . ch/~ecoopws 
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Abstract. This report summarizes the presentations, discussions, and 
outcomes of the ECOOP’2000 Workshop on Object Interoperability, held 
in Sophia Antipolis, Erance, on Monday, June 12, 2000. Divided into four 
main sessions, the workshop covered some of the most important issues 
related to object interoperability at different levels (such as protocols or 
semantics). This report has two main goals. First, it tries to provide a 
snapshot of some of the current research being carried out within the 
object-oriented community in these areas. And second, it summarizes 
some of the open questions and issues related to object interoperability, 
in order to set the basis for further research activities. 



1 Introduction 

In the Open Systems arena there is now a race under way between middleware 
architects and vendors to establish interoperational standards (e.g. CORBA, 
EJB or DCOM), as well as bridges among them. Those component platforms 
undoubtedly provide the infrastructural support for components to interoperate 
at certain (basic) levels. However, much work remains to be done by the object- 
orientation community in order to deal with all the complex aspects that object 
interoperability embraces in open systems. In this context, interoperability can 
be defined as the ability of two or more entities to communicate and cooperate 
despite differences in the implementation language, the execution environment 
or the model abstraction 0. 

In order to discuss some of the issues related to object interoperability, the 
first ECOOP Workshop on Object Interoperability (WOI’99) was organized in 
association with the 13th European Conference on Object-Oriented Program- 
ming (ECOOP’99), and held in Lisbon (Portugal) in June 1999. WOI’99 suc- 
cessfully contributed to gather a number of researchers interested in object inter- 
operability, and allowed them to start building a common understanding of the 
different problems and yet unexplored areas to be investigated. Basically, three 
main levels of interoperability between objects were distinguished at WOI’99: the 
signature level (names and signatures of operations), the protocol level (relative 
order between exchanged messages and blocking conditions), and the semantic 
level ( “meaning” of operations) . 

Although interoperability is currently well defined and understood at the 
signature level, this sort of interoperability is not sufficient for ensuring the 
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correct development of applications in open systems. Typical interface definition 
languages (IDLs) provide just the syntactic descriptions of the objects’ public 
methods, i.e. their signatures. However, nothing is said about the order in which 
the objects expect their methods to be called, their blocking conditions, or their 
functionality. Basically, current IDLs do not describe the usage, requirements, 
capabilities, and behavior of objects. 

The variety of topics covered during WOI’99 revealed the wide range of 
challenges that the study of object interoperability at both protocol and semantic 
levels brings out when objects have to interoperate in open systems. The list of 
questions and open issues was so long that we decided to organize a new edition 
of the object interoperability workshop, with the aim of promoting research 
concerned with all aspects of interoperability between objects, in particular at 
the protocol and semantic levels. 

2 The WOI’OO Workshop 

The second Workshop on Object Interoperability (WOI’OO) was held in Sophia 
Antipolis, France, in conjunction with ECOOP’2000. The main aim of WOI’OO 
was to provide a venue where researchers and practitioners concerned with all 
aspects of interoperability could meet, disseminate and exchange ideas and pro- 
blems, identify some of the key issues related to object interoperability, and 
explore possible solutions. As a WOI’OO new feature, special attention was drawn 
into some of the existing commercial object models, proposing extensions of their 
IDLs in order to cope with some of those interoperability issues, and discussing 
how to check them during compilation and run time in commercial applications. 
In particular, the topics of interest pointed out in the call for papers included, 
among others: 

— Extensions to object interfaces and IDLs to deal with protocol or semantic 
interoperability (especially commercial IDLs) . 

— Enabling models, technologies and architectures for object interoperability. 

~ Protocol and semantic checking techniques. 

— Industrial and experience reports. 

All submitted papers were formally reviewed by at least two referees, and 
10 papers were finally accepted for presentation at the workshop. Contributions 
were divided into four distinct groups: 

1 . In the first group we have the contributions describing experiences with com- 
mercial object models, encouraging the need of formalizing CORBA service 
IDLs and specifications. 

2. In the second group we find those focusing on protocol interoperability, in- 
cluding IDL extensions, protocol checking techniques, and some formal as- 
pects of interoperability at this level. 

3. Interesting experience reports about syntactic interoperability are found in 
the third group of contributions. 
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4. Finally, two contributions propose interaction frameworks for object inter- 
operability. 

In addition, this year we had a brilliant keynote speech by Prof. Mehmet 
Aksit, from the University of Twente, that opened the workshop. His talk served 
not only for introducing the topics related to object interoperability and the 
key concepts behind them, but also for setting up a common vocabulary and 
understanding among participants. There were many references to the concepts 
and the notations introduced by Prof. Aksit during the debates, which proves the 
invaluable help that having a keynote speaker represents. In particular, his talk 
significantly helped bringing all participants into a shared conceptual framework 
on which to base all discussions. 

The workshop gathered 13 people from 7 different countries, who actively 
participated in very lively discussions. Their names and affiliations are listed 
in Annex 1. This report has been put together with the help of all those par- 
ticipants, and summarizes the workshop presentations, discussions, and results 
obtained. It is structured in 5 sections. After this introduction, section 3 de- 
scribes the first three sessions, starting with a summary of the keynote speech, 
and the outcomes of the paper presentations and debates. Section 4 is dedi- 
cated to the last session, and contains some of the issues that were finally raised 
for discussion, the actions identified as post-workshop homework, and the final 
conclusions. This section also includes the discussions that took place after the 
workshop, during the production of this chapter, and the conclusions agreed. 

In addition to this report, a book with the Proceedings of the workshop has 
been produced [^, which contains the full-length version of all selected papers. 
More information about the workshop and its participants is also available at 
the workshop Web page: //webepcc. unex.es/juan/woiOO/. 



3 Presentations 

The workshop was divided into 4 sessions (two in the morning, two in the after- 
noon). This section describes the first three, which were devoted to discussing 
the presented papers. A brief outline of the ideas of the keynote speech and 
each presented paper is given, as well as some of the conclusions reached after 
each one. Those conclusions were written down in the blackboard, and finally 
summarized during the last session. 



3.1 Keynote Speech: Quality- Aware Interoperability (Mehmet 
Aksit) 

Nature evolution provides a good analogy for studying how (successful) products 
and systems should be built: every successful design of a complex system requires 
a proper decomposition, usually based on a solution domain knowledge. Similarly, 
every successful product displays a proper mix of quality factors, and is composed 
of well-balanced cooperating structures. Besides, every product must survive in 
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a competitive environment, and hence it should adapt to seamlessly cooperate 
with other products, and with its environment. 

Proper decomposition should be driven by balancing quality factors, spe- 
cially those imposed by the users’ requirements such as functionality, reusabil- 
ity, adaptability, or performance. So, software systems should be decomposed in 
such a way that the right mix of those factors is achieved. 

One effective way of reasoning about composition is by using the formula 
S3 = S2 (B Si, in which is what we currently have, S3 is what we need, S2 
represents what we need to add, and operator 0 models how we should add it. 
This expression allows to represent the different ways in which software systems 
are built. For instance, in an extension S\ exists but S2 is yet to be implemented. 
In composition both and S2 exist, and S3 has to be defined by composing S2 
and Si- In run-time adaptation the operator 0 can be provided by the system 
and applied at run-time, while in compile-time adaptation the operator 0 can be 
expressed within the adopted programming language and corresponds to writing 
“glue-code” (let it be inheritance or coordination, for instance). In addition, 
this formula also allows to measure the various quality factors, evaluating the 
different costs of reusability, adaptability, etc. 

On the other hand, cooperation requires compatibility and synchronization. 
In order to accomplish software compatibility, two main levels can be distin- 
guished — procedural and functional — , which deal respectively with syntactic 
and semantic agreements. Three are the main requirements for functional com- 
patibility: relevance, semantic compatibility, and realizability. Relevance is the 
most basic requirement, and means that both S2 and must be relevant for 
defining S3 . Semantic compatibility refers to the semantic consistency of the defi- 
nitions of both S2 and S\ for defining S3. Finally, realizability requirements cover 
the compatibility restrictions for the realization of the services and composition 
mechanisms (e.g., lack of expression power, extensibility or adaptability). 

Relevancy must be determined within the context of a certain business sce- 
nario, and can be assured by a successful requirement analysis process. In its 
turn, semantic compatibility needs synthesis and verification. The synthesis pro- 
cess aims at searching solutions from the solution domain and extracting the 
abstractions from the selected solution domain, while verification cares about 
having the sub-concerns of and S2 compared and verified for semantic com- 
patibility. 

Summarizing, interoperability becomes a necessity due to decomposition of 
systems into sub-systems (say S\, S2, Sn). Decomposition is by itself a compro- 
mise because of the necessity to provide a right balance between quality factors, 
such as functionality, reusability, adaptability, or performance. Interoperability 
requires proper decomposition based on a solution domain knowledge, and bal- 
ancing quality factors needs to be the driving force for decomposition. 

3.2 Experiences with Commercial Object Models 

Two papers were presented in this group, which outline some of the limitations 
of current CORBA specifications, and propose some ideas to overcome them. 
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3.2.1 Towards Components That Plug AND Play (R. Bastide, O. Sy) 

Just specifying the syntactic level of cooperation with IDLs, and informally des- 
cribing the behavior of objects does not necessarily lead to fruitful cooperation 
in an object-oriented system. In this paper the authors advocate that behavioral 
specifications of objects should be formal if they have to be non-ambiguous. 
They make their point by providing the conclusions of some interoperability 
tests conducted on five commercial implementations of the Object Management 
Group’s CORBA Event Service. These tests expose the non-interoperability of 
some implementations which trace back, on one hand, to the original specifica- 
tion’s incompleteness and, on the other hand, to mistakes in the implementation. 
The authors propose that the first cause be corrected by the use of a formalism 
suited to the needs of CORBA systems (like the Petri nets based Cooperative 
Objects formalism 0 ), and the second by the provision of test cases with the 
original specification. 

Two main conclusions were drawn from the discussions. Firstly, specifications 
in natural language are not enough because precision is needed. Specifications 
should be formal, and test cases should be provided to the user. However, al- 
though formal behavioral specifications are needed, they are not enough to ensure 
object interoperability. It is necessary to make requirements for interoperability 
explicit (see section 4.2) in order to make a conscious rational choice based on 
analysis of available design (and later technological) options. Secondly, since dif- 
ferent formal specification languages are available and provide different views of 
interoperability (levels of abstraction, performance, real-time, size, scalability, 
system modeling, system composition, etc.), there is an issue of selecting and 
combining these views (see section 4.3). However, in order to obtain this global 
view, one must consider the trade-offs: “all qualities cannot be obtained in one 
product” (cf. Prof. Aksit’s presentation). 



3.2.2 Adding Protocol Information to CORBA IDLs (C. Canal, L. 
Fuentes, J.M. Troya, A. Vallecillo) 

Traditional IDLs were defined for describing the services that objects offer, but 
not those services they require from other objects, nor the relative order in 
which they expect their methods to be used. In this paper the authors propose 
an extension of the CORBA IDL that uses a sugared subset of the polyadic tt- 
calculus for describing object service protocols, aimed at the automated checking 
of protocol interoperability between CORBA objects in open component-based 
environments. 

Once it is shown how CORBA objects’ interface descriptions can be enriched 
with protocol information, the authors discuss the sort of checks that can be 
carried out with their proposal (including some safety and liveness properties 
of applications, and component compatibility and substitutability checks), as 
well as some of its advantages and disadvantages. Furthermore, the authors 
also discuss the practical utility of their proposal, and present the limitations 
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encountered when trying to implement and use this sort of IDL extensions in 
open systems. 

Two main conclusions were reached after the discussions that followed this 
presentation. First, that interoperability tests can be costly due to their (intrin- 
sic) complexity. Nevertheless, including knowledge about the solution domain 
may significantly reduce the complexity of the tests. Secondly, it was also agreed 
that formal description techniques (FDTs) may not be enough for specifying 
systems: not all aspects and requirements can be covered by FDTs. 



3.3 Protocols 

The second session was dedicated to the discussion of interoperability issues at 
the protocol level. In our context, a protocol is a restriction on the ordering of 
incoming and/or outgoing messages, including possible blocking conditions and 
guards on the objects’ methods. Four papers were selected in this group, covering 
different proposals that address those issues from very different perspectives. 



3.3.1 An Enhanced Model for Component Interfaces to Support 
Automatic and Dynamic Adaption (Ralf H. Reussner) 

Current commercial component systems, modeling component interfaces as a list 
of method signatures, have several practical relevant shortcomings. For instance, 
they do not detect component compositional errors before the actual use of the 
composed system; besides, all adaptations of a component must be explicitly 
foreseen and programmed by the developer. The author addresses these problems 
by a new component model for Java: CoCoNut/J. A CoCoNut enhances a Java 
Bean with a clear COmponent interface COntract. This new interface model is 
regarded as a contract to deploy a component: the services that the component 
offers (call-interface) and the external services it requires from other components 
(use-interface). The call-interface models not only the available services, but 
also all valid call sequences to these services. Alike, the use-interface models all 
possible call sequences to used services of an external component. 

The linkage between both interfaces is explicitly modeled. When not offering 
a service in the call-interface we may also not require certain external services. 
Conversely, if some external services are not available, some of the component’s 
services may not be offered either. The author shows how this connection of the 
interfaces can be actually used to automatically (re-)compute the component’s 
call-interface with dependency from the existing external services. In the paper 
the author describes an extension of finite state machines with counters which 
are used to model the interfaces. With the two interfaces it can be checked during 
composition time (i.e., when the user awaits errors, and before run-time) whether 
two components A and B can work together, i.e., whether the protocol of the 
use-interface of A fits to the B’s protocol of the call-interface. 

Generalizing this check, component A can be adapted in the case the proto- 
cols do not fit, or component B is missing. The main idea is to exploit the linkage 




262 



Antonio Vallecillo, Juan Hernandez, and Jose M. Troya 



between the call-interface and the use-interface of component A. In case the use- 
interface of A does not match the call-interface of B, another use-interface of A 
can be built which matches the call-interface of B. This is done by constructing 
the intersection of these interfaces (the cross product of the automata). Af- 
ter having a new use-interface of A which matches the call-interface of B, the 
new call-interface of A can be generated out of A’s automata and its new use- 
interface. This restriction of functionality is a certain kind of adaptation does not 
have to be explicitly programmed by the component developer, and is available 
as a service provided by the component infrastructural system. 



3.3.2 On Practical Verification of Processes (Rick van Rein) 

When proving properties such as ‘compatibility’ on processes, the two customary 
techniques to use are model checking and theorem proving. Model checking is 
known for its speed and its ability to provide good feedback (to guide repairing 
faults), but it is limited to systems with a bounded number of process instances. 
This problem is an important drawback to computer scientific process verifica- 
tion, and for that reason we decided to look into theorem provers. 

Theorem provers are powerful proof tools that usually conduct their reason- 
ing at a fair speed. However, one problem of theorem provers lies in the low level 
of internal reasoning (logic, while a process designer tends to think in terms of 
process steps) and the resulting feedback (if any); another problem of theorem 
provers is the danger of infinite loops in the reasoning process. 

The problem of the low level of feedback can be solved by clearly distinguish- 
ing the interesting properties (proof attempts and axioms) from the cumbersome 
ones. A wrapper around a theorem prover formulates desired proofs of interesting 
properties and offers them to a theorem prover as subgoals. Internally, the the- 
orem prover exploits both interesting and cumbersome knowledge (axioms and 
previously proven properties) to attempt to achieve such subgoals. The collected 
successes and failures of these subgoals do not reveal the internal cumbersome 
proof steps, just their end result, which is in terms of interesting properties. 
These successes and failures provide the same information as collected by a 
model checker, hence the same useful feedback can be provided. 

The problem of infinite looping during the reasoning about proofs can be 
avoided by constraints that define a reasonable class of acceptable problems. This 
class of acceptable problems cannot be defined for logic in general, but the use 
of knowledge from the problem domain (processes) can help out. Consider that 
processes are associated (they refer to each other) and one way to avoid infinite 
proofs would be to avoid infinitely cycling through the process associations. 
This can be avoided by constraining the number of introductions of the quantor 
rules that describe these associations, and/or the number of introductions of 
the quantor rules that describe the processes themselves. Such an upper limit 
to quantor-rule introductions is a well-known solution to the danger of infinite 
looping. 
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In conclusion, this paper presents an approach to prove process-related prop- 
erties with theorem provers, in such a way that good feedback can be given and 
proofs always consume a finite time. 

3.3.3 Temporal Logic Based Specifications of Component Interaction 
Protocols (Jun Han) 

The interaction protocols of software components are critical to their proper 
understanding and use. Based on real-world experience in designing a telecom- 
munications system, the author presents a temporal logic based approach to 
the specification of component interaction protocols. The protocol specifications 
take the form of interaction constraints on a component’s required and provided 
signature elements (i.e., attributes, operations and events). 

After giving an overview of a framework for comprehensive and yet flexible 
component interface specification, the paper introduces a number of temporal 
constructs for specifying interaction constraints. Then, the types and placement 
of interaction constraints in the interface specification are analyzed. The pa- 
per also provides a comparative discussion with other protocol specification ap- 
proaches, including those based on description logics, Petri nets, state machines 
and process algebras. The author finds that the temporal logic based approach 
in the form of constraints is particularly practical as it is easy for practitioners 
to learn and use, and it allows incremental specification of interaction protocols. 

3.3.4 A Framework for the Specification and Testing the 
Interoperation Aspects of Components (I. Cho) 

This work proposes a component specification model that adds a protocol and 
behavioral aspects of a component to enhance the interoperability between com- 
ponents interacting to each other. The notation used for the specification is an 
extension of the OCL (object constraint language), which is a part of UML. One 
notable aspect of the work is the testing framework that integrates the spec- 
ification model, the syntax/protocol checker, the automatic test sequence and 
test code generator. The component specification model is an extension of the 
current industrial standards — CORBA, COM/DCOM, JavaBeans — , and aims 
at providing their components with more powerful interoperability tests. 

3.4 Syntactic Interoperability 

In this session two papers describe interesting experience reports about inter- 
operability at the signature level. 

3.4.1 A Multi-level Approach to Verifiable Correct Design and 
Construction of Multi-language Software (A. Kaplan and J.C. 
Wileden) 

The work by Alan Kaplan and Jack C. Wileden propose an approach for ma- 
king heterogeneous white-box components interoperate, defending the “interface 
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bridging” approach instead of the “interface standardization” approach that uses 
IDLs |5|. In particular, the work presented allows programs written in CLOS and 
C++ to transparently interoperate by means of a tool called PolySPINner. 

An interesting discussion about the real use of formal description techniques 
followed this presentation. It is clear to all that formal description techniques 
are far from being widely accepted and utilized in real industrial environments. 
In fact, type checking is the only practical, useful and accepted way of formal 
analysis nowadays. Furthermore, type definition is the practical limit which real 
users are willing to specify (and have reasonable chance of getting right). Several 
reasons can be argued for that: 

1. Semantic specifications are very difficult to write, and the computational 
complexity of their tests makes them impractical in most situations. Besides, 
we cannot forget the necessities and abilities of users to whom formal descrip- 
tion techniques may be useless. In practice, the more specialized/powerful 
the formal model, the worse the ratio pay-off/pain. 

2. Formal models (even types) always miss the aspects that turn out to matter 
in the real world, since they do not allow to capture many of the non- 
functional requirements involved in any real application. 

3. And finally, protocol specifications are seldom really useful or sufficiently 
precise, as previously pointed out. 



3.4.2 Interoperability Oviedo3/COM Objects through Automation 
(F. Dominguez and J.M. Cueva) 

In this paper the authors present an experiment of integrating a proprietary 
object-oriented system (OviedoS) with COM objects by means of wrapping the 
IDispatch interface. This technique allows COM objects to be perceived and 
used as native objects by the user, allowing an easy integration between both 
systems. 

3.5 Interaction Frameworks for Object Interoperability 

The two last papers dealt with interaction frameworks for object interoperability. 



3.5.1 Addressing Interoperability in Multi-organizational Web-Based 
Systems (A. Ruiz et al.) 

Current techniques for checking interoperability present a number of drawbacks 
that make it difficult to apply them in nowadays software industry. In this paper 
the authors identify some of these drawbacks, and present a proposal to tackle 
object interoperability from a new point of view: interoperability certificates a 
component must have been granted in order to participate in a collaboration with 
other components. Certificates are granted when a component passes a number 
of tests, and they are stored in a repository so that checking interoperability is 
a simple, quick process. 
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The authors also rise some questions in order to address the interoperability 
problem in the context of MOWS (Multi-Organizational Web-Based Systems) 
that are specially attractive in electronic commerce. MOWS have a number of 
features that transform them into special open distributed systems where the 
approach proposed by the authors may be realistic and attractive to software 
engineers. 

Finally, two open issues were risen: the need of a new interoperability level 
(the quality level), and the future of the certification techniques for checking 
interoperability. 



3.5.2 Interaction Ftamework for Interoperability and Behavioral 
Analysis (J. Putman and D. Hybertson) 

An interaction framework based on a software architecture perspective was pre- 
sented in terms of a set of views that address issues of interoperability and seman- 
tic behavior. The framework uses concepts from the Reference Model for Open 
Distributed Processing (RM-ODP, an ISO standard) . The views represent levels 
of abstraction, as a means of supporting distributed system interoperability. The 
architectural concept of connector provides the locus of relations, interactions, 
and protocols among components. The following views were defined: 

— The relationship view specifies that a relation exists between objects or com- 
ponents, and defines the interaction. 

— The interface view specifies the interfaces of each component, using a com- 
ponent model that allows multiple interfaces per component, within a tax- 
onomy of interface types. This view still hides distribution of components. 

— The binding view enables communication and interaction by focusing on 
connectors. It is a more concrete view in that it reveals distribution of com- 
ponents. 

— The interceptor view supports interoperating components in different tech- 
nical or administrative domains by addressing issues of cross-domain policy 
management and mediation. 

— The behavioral semantics view specifies the semantics of the interaction and 
the information/data involved in the interaction. It supports all the other 
views. 



4 Final Session 

The final session was dedicated to discuss some of the issues not covered during 
the previous sessions, to summarize the conclusions drawn during the presenta- 
tions into a final list of conclusions, and to select some actions for participants as 
homework. In addition, a number of discussions happened among the workshop 
participants by e-mail after the event. 

This section is dedicated to present the outcomes of those discussions, as well 
as the list of the workshop’s final conclusions. 
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4.1 Requirements for Interoperability 

In the first place, Duane Hybertson wanted to clarify which were the precise 
requirements for interoperability. The following definition (as prepared by Du- 
ane himself) was produced. It groups interoperability requirements according to 
where the resulting constraints (client side or server side) are located: 

Definition 1 (Requirements for Interoperability) . Given two eomponents, 
‘Client’ and ‘Server’, four general interoperability requirements, or classes of 
requirements, are proposed: 

R1 Data Constraints. Data received by the Client from the Server must satisfy 
all client-side data constraints, including constraints on types, content, units, 
and quality. 

R2 Services Constraints. Services received by the Client from the Server must 
satisfy all client-side service constraints, including functionality (or other 
relation between input and output such as precondition and postcondition) , 
sequence, timing, and quality of service (QoS). 

R3 Request Constraints. Services requested by the Client from the Server must 
satisfy a set of server-side preconditions before they are permitted access to 
those services. In turn, the Server must satisfy its postcondition (including 
both functionality and QoS postconditions) in providing the service. 

R) Control Constraints. All components (clients and servers) involved in an 
interaction must have a consistent expectation regarding transfer of control, 
including blocking conditions. 



4.2 Levels of Interoperability 

During the discussions the group did not agree with the original taxonomy of hav- 
ing three levels of object interoperability. Are protocols part of semantics? Are 
semantics just about behavioral specifications? The following two paragraphs ex- 
tracted from the e-mail discussions summarize the debate that took place about 
this taxonomy: 

Antonio: ...Yes, we could start arguing about the taxonomy “signatures/pro- 
tocols/semantics”. In this point it could be worth having a look at last year’s 
WOI report [Hj. Of course you can stick to the “traditional” signature/semantics 
taxonomy (also called static/dynamic in [5], or plug/play by Sy and Bastide in 
the workshop). Even in this case the “semantic” level may include too many 
things. If we take a look at the literature, most of the authors that say “se- 
mantics” mean “operational semantics” or “behavioral specifications”. So far 
people have concentrated in signature interoperability (just method names) and 
operational semantics (using various formalisms: pre-post, temporal logic, pro- 
cess algebras, etc. — the new book edited by Leavens and Sitaraman compiles 
many of the approaches that deal with the semantic aspects of components 0). 
However, the “semantic” level is too broad. It should cover not only operational 
semantics and behavioral specifications of components, but also agreements on 
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names, context-sensitive information, agreements on concepts (ontologies) — 
which moves names agreements one level up in the meta-data chain — , etc. (All 
this is very well described in the papers by Sandra Heiler, eg. i)- The problem 
is that this is a too broad and general problem to be tackled in full. 

On the other hand, dealing with behavioral specifications needs very heavy 
machinery, which makes unpractical most approaches for real applications. One 
possibility that was originally proposed by Yellin and Storm in 1994 (inspired 
by the works by Nierstraz j7], and Allen and Gar Ian 0) was to deal just with 
the “protocol” aspects of the behavior of components. In this way more practi- 
cal tests could be defined for proving interoperability among components, and 
actually this has traditionally been the interoperability “level” used in most 
Architectural Description Languages.... 

Duane: ...As Antonio has indicated, the concept of “semantics” covers a very 
broad set of issues, and there is no universal consensus on the full scope of what 
those issues are. This is not surprising, given the difficulty of the topic. I would 
simply add that we should be realistic and view “semantics” as a topic that 
is likely to develop and mature over a lengthy period, perhaps even decades. 
That is, rather than a sudden revolution in understanding semantics, what may 
happen is a kind of extended factoring process. Relatively small aspects of the 
problem will be defined more precisely, solved, and removed from the big, fuzzy 
bin of what we now call “semantics” . The process would be somewhat analogous 
to the way issues and methods once grouped under “artificial intelligence” are 
now simply considered useful tools of everyday software engineering. Such a fac- 
toring process for semantics could for example explain why we tend to separate 
semantics from issues such as signatures (which we understand well) and proto- 
cols (for which we are gaining a good understanding), even though both of these 
topics have semantic aspects. As topics are factored out, they may be positioned 
at different levels, perhaps in something like a lattice structure. Over time the 
gradual clarification and removal of well-understood topics from the semantics 
bin will both reduce the size of the semantics problem and help provide a new set 
of tools for resolving the remaining issues. At the same time, though, I think it is 
important to preserve an overall understanding of how a thread of semantics is 
woven throughout all of these areas. That thread begins with topics as “simple” 
as signatures and extends through issues so abstract that at present we do not 
even know how to name them. Recognizing this thread of semantics should help 
us in time to arrive at a deeper and more profound understanding of semantics. 
Our achievement of this understanding will certainly come in increments, and is 
not fully articulated by the three-level taxonomy at this time.... 

4.3 Workshop Conclusions 

Finally, Jack Wileden did an excellent job summarizing the workshop conclu- 
sions into the following list. Those conclusions represent the ideas agreed by all 
participants. In addition, this list also points out some of the existing problems 
that object interoperability currently faces, and provides some hints to their 
solutions that may be worth investigating. 
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I. Interoperability is an (increasingly) important concern. 

II. Support for interoperability should/must include: 

• Careful specification of the components and their properties. 

• Precise notations of compatibility (composition). 

• Automated tools for constructing, analysing, composing components. 

III. Candidate (potentially viable) specification methods include: 

• Signature/types {sine qua non, i.e. fundamental). 

• Protocols (partial orders of signature invocations). 

• Behavior (results of sequences of signature invocations) . 

IV. Underlying formal models are potentially powerful. Valuable specific 
strengths and weaknesses should continue to be investigated. 

V. Underlying formal models should be hidden as thoroughly as possible (both 
on inputs and output states) from most users. 

• Automatic derivation/inference is a promising possibility. 

VI. Other important considerations: 

• Multiple levels of abstractions should be considered. 

• Solution domain (in addition or alternative to implementation domain) 
driven decomposition. 

• Connections to software architectures (and other related research ar- 
eas). 

• Possibility of defining patterns for interoperability. 

5 Concluding Remarks 

If a main goal of a workshop is to gather researchers and practitioners of a 
discipline, and let them exchange ideas, identify problems, and reach (violent:) 
agreements, we are pretty sure we succeeded with WOI’OO. The present report 
has collected (most of) the discussions that took place during and after the 
workshop, and the conclusions that were finally agreed. 

Much work remains to be done in this area of object interoperability, but we 
hope that WOPOO, as its predecessor WOP99, has provided the basis for concrete 
research activities in this field, and that following WOI’s serve as a stable forum 
for discussion on these topics. 

Before we finish, we would like to thank the ECOOP’2000 organization for 
giving us the opportunity to organize the workshop, especially to the Workshop 
Chairs, Sabine Moisan and Jacques Malenfant. Thanks also to all the contribut- 
ing authors and to the referees who helped in choosing and improving the selected 
papers. Finally, we want to especially thank all WOI’OO attendees for their ac- 
tive and enthusiastic participation in the workshop, and for their contributions 
to this report. Many thanks to all for making WOI’OO a very enjoyable and 
productive experience. 
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Abstract. Security of e-applications running over Internet is a major 
requirement for their widespread use. As discussions in this panel often 
pointed it out, such kind of applications shows more and more a pro- 
perty of mobility: mobility of code, data, or even mobility of objects, 
termed agents. But how to enforce security of such mobile components ? 
Is it at the programming language level, or could it be managed in a 
completely transparent way for the programmer ? Do we need domain- 
specific languages that we hope could be trusted or are general-purpose 
languages enough ? This panel gave some highlights on how adequate 
the object-oriented language technology could be; at which level of gra- 
nularity security has to be designed and introduced into the application; 
why solutions differing from classical cryptography-based solutions are 
promising. 



1 Motivations 

This section presents the key points about Internet, security and electronic com- 
merce, which is the main e-application going over it. 

Internet is the first truly global network in the geographical, social and tech- 
nological sense (IP is becoming the common denominator for almost all commu- 
nications including wireless ones). New problems that are specific to Internet, so 
new security requirements, have appeared: one origin to these problems is fun, 
i.e. hackers which disseminate attacks in terms of scripts, the result being denials 
of services. An other origin is that business transactions are carried over an open 
public infrastructure, and last but not least, critical services use Internet as the 
unique communication infrastructure. 

What are the solutions for security on Internet ? There is the cryptographic 
security train where we tend to use the cryptographic operations (encryption, 
digital signatures, integrity, etc) to protect end-to-end operations. An almost 
opposed direction is based on firewall where there is no cryptography at all. 
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just filtering operations. Both types of existing solutions lead to a separation of 
Internet into administrative domains with strict boundaries. 

What happens in terms of computing models ? In parallel with the advances 
of network technologies, there has been advances in computing stated in terms of 
distribution, decentralisation. It started with network operating systems, then 
distributed systems, which are both static models without any data or code 
mobility. The current computing model can be summarised as extensive sharing 
of components and mobility to support this sharing through which components 
(data, code or objects) are moved over the network. 

Putting this current computing model together with the current security 
solutions raise several questions: are they compatible, or. . . non sense ? Indeed 
if we continue implementing security the way we do with strong administrative 
boundaries, there might be a problem regarding the computing model which 
requires mobility. 

Considering more deeply mobile objects and security raises some questions: 

— a classical problem is how to protect the local runtime environment, com- 
ponents, with respect to the code and data that come from other sources. 
Some practical solutions such as the sandbox model, code signing do exist. 
But are these solutions sufficient ? Do we need finer granularity to protect 
components ? Very interesting solutions from research like Proof-Carrying 
Code, other works in computer science like holographic proofs are not yet 
practical solutions. 

— a less classical problem is protecting the component that you send to remote 
locations against attacks on harmful operations that could originate from 
the hostile runtime environment itself. It is conjectured that there could be 
no solution to this without trusted hardware support. Few solutions exist 
but they are far from being practical (encoding one bit, . . . ). 



2 Issues 

The panel members discussed mobile code, Internet security and e-commerce 
from the programming viewpoint, by addressing the following issues which can 
be classified as: 

quite general-purpose: 

— How to manage the complexity of securing e-commerce, Internet appli- 
cations ? 

— In particular, how do we protect the exchange of XML documents ? 

~ Do we need scalable security mechanisms, for instance regarding authen- 
tication ? 

oriented towards language design and application design: 

— Is it possible to write high quality code that is concurrent, distributed 
and secure ? 

— Can the language help ? Can an object-oriented language help more ? 
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— If nearly all code can be mobile, how should it be structured, at which 
level of granularity ? 

more specifically oriented towards security: 

— How to express security properties of an application ? 

— How much formal approaches (like Proof-Carrying Code) can be helpful ? 
— Is it possible to reason about security from the program text ? 

— Can we trust the language ? 

— Do we need domain-specific languages ? 

— How to manage dynamic binding from the security point of view ? 

Presentations are related here in such an order as to indicate the breadth of 
interest in the topic, from general to specific: 

— Protecting XML documents - Elena Ferrari 

— The issue of using object-oriented technology for building secure systems - 
Ciaran Bryce 

— The ubiquity of mobility and some design guidelines - Doug Lea 

— Language-based security - Cedric Fournet 
~ Proof-Carrying Code - Peter Lee 

The following sections provide highlights from the panelists position papers 
and presentations. 



2.1 Elena Ferrari. University of Milano, 
http : / /homes . dsi .unimi . it/~f errarie 

As XML is becoming a standard for exchanging documents over the web, pro- 
tecting them is an important issue. Even if XML “turns the web into a database” 
(J. Widom), protecting XML documents is different from protecting information 
stored into a database. Main issues for this specific protection are discussed. 

Requirements of an access control model for such kind of documents. 

1. Need to support a wide range of protection granularity levels: on one hand, 
for instance, a single document can contain informations at different degrees 
of sensitivity, so the need to apply different policies to the same document; 
on the other hand, a same policy could apply to a whole set of documents, 
and so it would be useful to attach a policy at the document type level that 
will automatically propagate to all instances. 

2. Definition of credentials using user characteristics, profiles, instead of using 
an identifier as traditionally done in database environments. 

3. Need of policies to protect both valid documents (with an associated type or 
class as in object-oriented databases) and well-formed documents (following 
the XML syntax but not conform to a type) . 
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Ways (architectures, methods, . . .) to disseminate the information according to 
the specified policies 

— Information pull strategy (commonly used in database environments): the 
source checks the authorisation policy and returns to the user from which 
the request came, only those portions of the document he is authorised to 
have access to. 

— Information push strategy: the source periodically broadcasts documents to 
users (newsletters, monthly reports, . . . ) without the need of an explicit 
request. Sensitive portions of a document can be encrypted with different 
encryption keys, so as to send the same encrypted copy to all the users, but 
to each user only the key he needs to get the view of the document he is 
allowed to access. 

Performance evaluation, both theoretical and experimental are needed to decide 
which strategy is better and under which circumstances. 

Distributed doeument modifications (of both structure and content) 

— must be regulated by proper authorisation policies 

— usually must follow a predefined path for updates 

Digital signatures based approaches, but probably other technics are needed. 

2.2 Ciaran Bryce. Centre Universitaire d’Informatique. University 
of Geneva, http://cui.unige.ch/~bryce 

The fundamental question is “when I’m programming an application, do I have 
the right tools to integrate security into that application ?” . Many people believe 
that object-oriented programming is the best programming paradigm that exists 
to integrate security. Indeed, it has some features (encapsulation, visibility con- 
trol, inheritance) which at first seem to be quite convenient. So, the fundamental 
question turns out to be “can we build secure systems using object-oriented tech- 
nology ?” . But the answer seems to be no as it will be shown how difficult it is 
to integrate security: 

— Encapsulation: methods are a good place to put access control checks. But 
when encapsulation is enforced in a language, it is too fine a granularity as 
in practice, we want to separate components, a whole program, from the 
rest of the system. An other problem comes from aliasing which is a way to 
easily share information in object-oriented programming. Statements about 
security can hardly be made when one does not know who is accessing what 
information. 

— Visibility control (like with packages, public, private modifiers) enables to 
hide part of the system. The problem is that it protects access to classes, to 
code, but it does not mean that it hides objects (if one declares a variable 
as being private, it does not mean that the object linked to that variable is 
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private and access can be gained to that object with aliases). Some of the 
security flows which are documented in Java have come from this misunder- 
standing. 

— Inheritance has been shown to ease security integration but it is one way 
of introducing Trojan horses into the system. With dynamic binding for 
instance, a class can be introduced into the system, but this class contains 
a loop or blocks the program . . . 

As it is even not sure that we can trust the basic tools we have for developing 
applications, we must now raise where are the issues of mobile code (which is 
not only a research domain but interests also the industry) and mobile objects. 

Mobile code is defined as code that is loaded from the network rather than from 
the disk at the time it is needed in a running program. The main issue is trust 
management, i.e. what privileges should be given to foreign code. But it is not 
clear that this is a new issue as code loaded from the disk probably came from 
the network at some time. Recall that you do not need a network to get a virus ! 

A potential technology called agents is not only to move code but objects, states. 
This way, programs are executing much closer to the resources they need, so 
network costs can be saved. A typical example lies in an agent for airline reser- 
vation that visits many sites to look for the best price. Basic elements of mobile 
agent security are: 

— isolation of an agent from the rest of the system such that for each resource 
access, the security policy is applied; accounting and control of resource 
usage. These are - not new - typical issues in operating systems, studied for 
40 years. 

— Believability of information furnished by the agent, which requires the use 
of a public key infrastructure. Be careful that such kind of structure which 
is one of the basic functionalities we are lying upon to build secure systems, 
can not always be trusted in practice . . . 

— Survivability of agent computation is an important point, especially because 
this trusted computing basis might not already exists. 

— Risk analysis for e-commerce (developed in hand with business models) is 
required to estimate the cost if something goes wrong. 



What can we do as programmers with all the complexity we are faced, when 
programming security for e-commerce Internet applications ? 

1. Be able to do the simple things well. 

2. Be able to give and justify simple statements about security, e.g. 

— a class C is only loaded from a trusted directory, or 

— an object O is never referenced by another program, or 

— if an object is coming from the network, be sure that a certificate is 
attached to it. 
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To do such things, the languages have to help us (with notions such as protec- 
tion domains, containment of references within a program) which is not perfectly 
the case for the moment. Ideally, we should be able to understand from the text 
what a program is doing from the security point of view (isolation, containment, 
etc). 

2.3 Doug Lea. State University of New York at Oswego, 
http : //gee . cs . oswego . edu/ 

Mobility is ubiquitous. It is amazing how much mobile code is already out there: 

— applets, XXXlets, .... Nearly all the possible billion of wireless devices will 
have JVMs and all these will be running mobile Java code. 

— remote execution with RMI (a mobile code framework masquerading as a 
remote message facility, but with dynamic class loading, serialization, etc) 

— agent frameworks, . . . 

Because nearly all class you write in Java could find this way into some 
mobile framework, how should this code be structured ? 

In the small , i.e. at the level of data: confinement, encapsulation, safety, that 
is, making sure that a class is as self-contained as possible. It used to be a 
merely good design, and now it is becoming essential design. 

At the medium level , i.e. at the component level. Security and resource man- 
agement are issues raised at this level. As a component is the unit of mobility, 
there are some requirements in order to make components behave themselves 
as good clients: in protocol negotiation frameworks like Jini; in event-based 
transactionality frameworks like EJB, where disconnections, security viola- 
tions, permission denial violations happen all the time. 

In the large , i.e. at the system level: here are required the major heavy services 
like authentication. 

Following a pattern, a way of structuring code at the level of data, and 
transactionality at the level of behaviour become central things in the design 
patterns of the short term future for creating mobile code. 

2.4 Cedric Fournet. Microsoft Research, Cambridge, UK. 
http : / /research.microsoft . com/~f ournet 

Security concerns are one of the main reasons why distributed mobile agents, 
or mobile code are not more widely used today. In fact, it is a very appealing 
approach, but if you can not control security, it is useless. However, much simpler 
systems are badly broken as regard security. Two alternatives are considered. 
One is to make sure that you cannot do anything dangerous with any agent, but 
then you cannot do anything useful. An other is to provide a large variety of 
almost independent security mechanisms, explain how they are implemented to 
the programmer and leave him deal with the assembly of such mechanisms. But 
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it is too low-level and in practice, as it is hard to understand the implications of 
writing a piece of code, the programmer has no chance to get confidence in the 
security of its code. 

In fact, code mobility itself is not the main security issue. What really matters 
are the data and the capabilities, the rights that are attached to a piece of 
running code. But this issue is quite blurred because in many systems with 
mobile agents, the environment is dynamic (due to dynamic linking, including 
of local libraries) . 

It is the access to these capabilities which should be important, not really if 
the code is running locally or on a remote machine. To make the point, let us 
take one example: if the code is running locally as it has moved, the host machine 
checks that the interaction with the local components are compatible with the 
capabilities that were given to that code (the sandbox model); if the code is 
not mobile and execute remotely using more traditional technics like RPCs and 
RMIs, the interaction with the remote components need also to be controlled 
thanks to the capabilities. But now, a firewall filtering, instead of local checks 
in a sandbox model has to be done. What is required is that regarding access 
control, the sandbox or the firewall should enforce exactly the same things. 

A major problem regarding security is to deal with multi-party computations 
where many components coming from different places are willing to do something 
together, but are reluctant to trust one another. Administrative boundaries en- 
forcing different security policies with different mechanisms must be taken into 
account. But with mobile code, administrative boundaries do not coincide at all 
with the physical boundaries; so the physical localisation of components is just 
an additional constraint or an opportunity for attackers. 

To tackle all this complexity, we need a good language whose support would 
be able to deal with these administrative boundaries and whose abstractions 
would enable to be able to reason about security of systems as a whole, not just 
from one single runtime viewpoint. In other words, we would like to think of 
security in a nice abstract model where we do not really care about machine 
boundaries. 

Designing the features of such a language as well as providing for it a strong 
secure implementation are the main points. Suppose that you design some scop- 
ing rule for variables in the high level model. Depending on the underlying run- 
time support, implementing that rule could be easy, or could require cryptogra- 
phy, or could be just impossible. So today, the features that can be implemented 
safely and in a secure way are: 

— asynchronous communication for most types; 

— authentication can be guaranteed taking advantage of a public key infras- 
tructure; 

— code integrity can be checked using byte-code verification. 

Extending this approach for mobile objects is much harder because it seems 
difficult to provide an implementation that will not depend on additional as- 
sumptions over what an host machine can do. 
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There exists some actual but marginal situations where code mobility in itself 
would be useful to increase security and ease its implementation, that would be 
more than some efficient implementation technic for distributed computations. 
One classical example is to use agents to run applications in safer places, in 
meeting halls a la Telescript. 

As a summary, language-based security is the way, as it enables 

— to specify what we mean by security and to explain it to persons writing 
programs, 

— to express high-level security policies, 

— to provide efficient, hopefully secure implementations (compilation). 

The language (at least the model) should express distributed, multi-party com- 
putations as a whole, otherwise there is no chance to understand what is going on 
from a local viewpoint . Even if for this model, it is quite possible that you might 
not be able to implement all guarantees everywhere, the model is still interesting 
as long as you can in advance determine for which parts of the computation it 
is unsafe to send and execute them on remote sites. 

2.5 Peter Lee. Carnegie Mellon University, 
http : //www. cs . emu. edu/'petel 

Some market research based observations and conclusions regarding the prolif- 
eration of mobile and wireless devices: 

1. The world is becoming wireless; phones: 1 billion by 2003; bluetooth-enabled 
devices: 670 million by 2005; 95 % of phones will be WAP and 70 % bluetooth 
by 2004 . . . There is going to be a really huge demand of very dynamic 
wireless networking. As battery power costs, performance and bandwidth 
will still be precious. 

2. A large quickly growing segment of the computing devices market are var- 
ious forms of network appliances such as for instance, ones that regularly 
download pictures in jpeg format from the web. Reliability and longevity 
are also expected. As an enormous diversity of platforms is expected, it is 
highly unlikely that it would be standard platforms. The challenges will be 
to get standard operating systems and even standard languages to run on 
these. 

3. As bluetooth transmitters will be put in every shipment, new commercial 
scenarios can be imagined (a transmitter pushes some applet on your PDA 
and start a negotiation asking you to buy 4 boxes of macaroni for example !). 
So commercial drivers will create demand for push technologies. 

4. The market may favour open systems instead of close ones. 

The implications are: 

— performance will always matter; 

— extensibility of systems, that we can call mobility, will be a desirable aspect 
for most computing platforms; 
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— a software development standard will be through well-defined languages; 

— scalable security to deal with a huge number of parties in those future sce- 
narios is required. It is not clear that cryptographic approaches are really 
scalable, as opposed to Proof-Carrying Code ones for instance. 

The basic idea of Proof-Carrying Code (PCC) is to provide a kind of confine- 
ment or safety at the code level by attaching mathematical proofs (i.e. convincing 
and easily validated explanations) to “dangerous” instructions. 

Programming language technology is a fundamental enabling technology that 
is not just the design of a language, of a virtual machine, but also an underly- 
ing theory that has been developed for several decades (in formal semantics, 
type theory, applications of logic, category theory, a.s.o.). Moreover, these for- 
mal approaches (e.g., PCC, TAL, kVM) are getting closer to reality. So language 
technology is the basis for performance, extensibility, scalable security and di- 
versity. 

3 Questions and Answers 

Question (R. Molva): why cryptographic solutions would not scale ? 

Answer: (P. Lee) In future bluetooth scenarios like those mentioned before, 
there could be a lot of parties for which the same question “do I trust it” should 
be asked, ahead of time and on a small memory device. So, somehow you want 
to have, at least for simple transactions, the ability to just simply trust anybody 
without sharing secrets, such as done with Java, PCC. (C. Fournet) I do not 
think cryptography can not be useful for these transactions. It is quite easy, if 
you are going to download an applet, to also download a certificate and check its 
signature by someone you trust. In practice, you do not need that many trusted 
signatures. 

Question (D. Caromel): what is the good granularity to have at the language 
level, regarding security ? How to justify that you might need security on classes, 
also at the component level but at the same time, also at the level of objects ? 

Answer: (C. Bryce) In a program which manipulates some objects, it may be 
the case that you declared some of them as private meaning that they will never 
leave the scope of your program. Those that are not private can be shared with 
other programs. But the granularity of security in real systems is bigger as you 
want to isolate programs (several classes and objects). 

Question (D. Caromel): As we would like to see the security from the program 
code, it seems to me that it would be hard to add things to the language in order 
to make the security explicit in terms of the constructs. 

Answer: (C. Bryce) When you look at the program text, sharing a subset of 
your objects is typically an operating pattern. When you write your program, 
it should be clear from the code, from the way you have written it, which ob- 
jects you can share, which you cannot. (D. Caromel) But the location in the 
code where you create objects follow a dynamic scenario . . . (C. Fournet) If you 
really want to see simple obvious security in the program, then it will not be 
good enough to add more and more mechanisms to an existing general-purpose 
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language. So, one way to proceed is to take a very simple language for a class 
of applications and security properties you care about, and obtain a domain- 
specific language. For it, you even may be able to prove formally that everything 
goes true with respect to these particular properties. (R. Molva) A more contro- 
versial view: as security in networks exists already, the problem is only to retrofit 
it in existing applications. That is why firewalls are so widespread because no 
change in the existing applications and existing protocols features are required 
(even if they are not the ideal solution). Language approaches seem to me to 
be the opposite as it is not transparent at all. The best would be to relieve the 
programmer completely from security concerns. He should be able to write a 
program without carrying about security, but that should be something below 
(maybe in the compiler, or in the runtime environment) that takes care of all the 
security aspects. Maybe PCC is one way of doing that because you do not have 
to program in a special way to be able to verify properties. (D. Lea) If you write 
code without having a regard for security, then you do not understand your code 
and you do not understand security . . . 

Question: It seems that everybody here is talking about static ways of trust, 
and the technology which is type safety can catch all these things. 

Answer: (P. Lee) Indeed, the community has underestimated how much can 
be done using these kind of approaches. For instance, even many types of resource 
constraints properties can be captured with these kinds of type systems, PCC, 

Question: Is it possible to write high quality code that is concurrent, dis- 
tributed, secure, etc, without knowing anything ? 

Answer: (D. Lea) One way is to search at the language front and to try to 
find domain specific languages, restricted languages for expressing things. An 
other approach is a sort of EJB style that puts this code in a container, provides 
us with some well-known services, so that the programmer can only write the 
GUI code and leaves the rest to the system. There is also the AOP approach 
that separates the concerns that make the actual code, so make the process more 
manageable for non-experts. 

Question: This is so difficult to negotiate this multi-dimensional space with 
security, concurrency and distribution . . . Can we establish some simple property 
points that people consider it is the default and understand what the features 
are, without having to understand all the details of the whole space ? 

Answer: (D. Lea) The fundamental problem in most systems is failure. Se- 
curity, distribution, concurrency cause programs to fail. Because responses to 
failures are very difficult to encapsulate, you have to expose them to program- 
mers as you can only sometimes hide them. (P. Lee) One approach which seems 
to be to me ignored in software engineering is making things simple. (C. Fournet) 
I do not know what you mean by simplicity ! Encapsulation is simple, packages 
are simple but not good enough for security. Simple does not mean easily secure. 
(R. Molva) The best simplicity is relieving the programmer completely from se- 
curity concerns and taking care in the compiler, in the runtime environment. 
You can make very good languages: Java 2 provides a lot of means to define the 
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best policy, but how many people are able to take advantage of Java 2 features ? 
(C. Fournet) You should program with security in mind from the beginning. It 
is very hard to take an even simple existing system, retrofit security in it and 
understand what is actually guaranteed. You can not hope the system to have 
uniform solutions that will not care about what the application is doing. 

Question: Bindings are good and the only times progress has been made in 
programming languages is when you can push things together. So, as some of you 
told us that they would really like to do things statically. I’m totally confused. 

Answer: (P. Lee) Something has been confused over and over again: in fact, 
the account of early or late binding and then static versus dynamic checking 
are completely orthogonal. In a secure system that makes use of late binding, 
of whatever kind of wrapper technology, we still need to know ahead of time 
that everything is going to be done properly and correctly before executing that 
program. You can not just late bind and wait to see if transaction passes. The 
need for some type of static analysis and verification is still always there. It is 
orthogonal to the binding issue. (D. Caromel) It is right that you do need late 
binding and can still do static checking but it becomes a lot harder as data flow 
and control flow interact together. (P. Lee) That implies that if you care about 
security, reliability, safety, predictability of systems, then you probably will want 
to surrender to late binding. (C. Fournet) If you still want to do late binding 
anyway, then you should be very explicit about it, let you see where it occurs and 
so get a chance to control it; late binding is embarrassing for security because it 
is fully implicit. Dynamic explicit binding would be OK. 
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1 Introduction 

Posters provide a medium to describe work in progress and to elicit feedback from 
the 00 community. This report gathers contributions from fifteen posters that 
were on display at the exhibition during the conference period. The adaptability 
of object oriented software was the emergent theme from this session. This theme 
was discussed from a technological point of view, either through reflection or 
aspect oriented programming, but also from an application domain point of 
view, considering for instance persistence, roles and cooperation. 

2 Behavioral Compatibility in Concurrent Object 
Constructions 



Michel Augeraud 

L3i - UPRES EA 2118, Avenue Michel Crepeau, 

F-17042 La Rochelle Cedex 1, France 

Inheritance and concurrency are not independent concepts. In the context of 
the active objects, O Nierstrasz proposes to define subtyping by means of the 
” request substitutability ” concept [55] • The example below shows that this 
concept does not define the compatibility between objects behavior when they 
are linked by a structural relation such as inheritance or aggregation. 

Example 1. The behavior of an object O of class C 2 consists of ” ” a concurrent 
execution of two methods m\ and m 3 follow-up, when the two preceding ones 
finished or only one having begun this one terminated, by the execution of a 
method m 2 ” (one will note (mi|||m 3 );m 2 this behavior). And C 2 inherits the 
class Cl defining as behavior the sequential execution of methods m\ and m 2 (one 
will note mi; m 2 this behavior). The initial state of Ci is ” request substutitable 
” with that of the initial state of C 2 ). 

We propose a definition of the compatibility of objects behaviors based on 
the comparison of the various evolutions which the systems of transitions which 
represent all possible behaviors, can have starting from their initial state |5]. For 
that we use h* who projects a trace c formed on a set EV 2 of events in the set of 
traces formed on a subset EVi of events. And we also use sets failures {initjH -^ ) 
of the couples (c, R) where c is a trace of A\ and R a set of impossible events in 
the state at which one arrives afterwards c. 
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Definition 1 . Being given two classes C\ and C2 such that C2 inherits C\ or that 
C2 he an aggregate of which one of the component belongs to the class Ci, the 
behavior A2 of C2 is compatible with that A\ of C\ if the following properties are 
checked: tracesj^^{initj^^) C traces j,^{initj^^) VC G tracesj^^{initj^^),{h*{c), 
R) G failures j^^{initj^^) ^ {C,R) G failuresj^^{initj^^). 



3 Evaluating Persistence Models 

Irina Astrova 

TietoEnator Eesti AS, Hobujaama 4, 10151 Tallinn, Estonia 
irina . astrovaOtietoenator . com 

There are many different parameters that can be used to evaluate the persistence 
model alternatives, and there is no single most correct process for conducting 
this evaluation. Not only are there many possible pertinent evaluation criteria, 
but there also is typically a degree of uncertainty about the requirements and 
expectations of persistence from the programming language and database man- 
agement system perspectives. Depending on which of these perspectives is more 
dominant in an implementor’s view, some parameters become more ’’correct” 
than others. For example, from the programming language point of view, it may 
be desirable to have dynamic, explicit, transparent and orthogonal persistence; 
while from the database management perspective, restricting persistence to the 
complementary set of choices - static, implicit, visible and non-orthogonal - may 
be more appropriate. A summary of the two perspectives is given in Table 1. 



Programming language perspective Database management perspective 


Incomplete 


Incomplete 


Dynamic 


Static 


Type orthogonal 


Type non-orthogonal 


Transparent 


Visible 


Explicit 


Implicit 


Name orthogonal 


Name non-orthogonal 


Support for garbage collection 


Support for explicit ’’delete” 



Table 1 . Viewpoints on persistence 



A persistence model explains how to program in the presence of transient and 
persistent objects. Thus, it defines the way in which the objects are created and 
deleted. It also specifies how the objects can eventually change their lifetime. To 
examine how these issues have been dealt with, we have given a brief run through 
of the main types of persistence, that are proposed or implemented in persistent 
programming languages or object-oriented database management systems, and 
for each have outlined its advantages and disadvantages. 
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The main types of persistence are: 

on creation', an object becomes persistent, when it is created, 
by allocation(also called by declaration or by storage): an object becomes per- 
sistent, ’’either when it is declared a persistent variable or when it is allocated 
within a persistent collection” |63| . 

by inheritance (also called from virtual base class): an object becomes persis- 
tent, when its class inherits persistent capabilities from a predefined virtual 
base class, 

by type: an object becomes persistent, when it is instantiated from a persistent 

type, 

on demand: an object becomes persistent, ’’when it is issued an explicit message 
to make itself persistent” m, 

by reachability (also called by connection): an object becomes persistent, when 
it is reachable from a persistent root. 

In looking at the advantages and disadvantages of these types of persistence, 
we have examined them under a total of seven evaluation criteria: 

— completeness, 

— dynamicity, 

— type orthogonality, 

— transparency (also called persistence independence), 

— implicitness (also called persistence identification), 

— name orthogonality, 

— support for garbage collection. 

Table 2 summarizes our examination. 



Persistence model on by by by on by 

creation allocation inheritance type demand reachability 



Complete 


Yes 


Yes 


Yes 


Yes 


Yes 


Yes 


Dynamic No 


No 


No 


No 


Yes 


Yes 




Type orthogonal 


Yes 


No 


No 


No 


Yes 


Yes 


Transparent 


No 


Yes No 


No 


Yes 


Yes 




Implicit 


No 


Yes No 


No 


No 


Yes 




Name orthogonal 


Yes 


No 


No 


No 


Yes 


Yes 


Garbage collection No 


No 


No 


No 


No 


Yes 



Table 2. Evaluation of persistence models 
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4 Join Point Aspect: A Solntion to Simplify 

Implementation of Aspect Languages and Dynamic 
Management of Aspect Programs 

Laurent Berger 

Laboratoire I3S (UNSA/CNRS), Team Rainbow, Sophia Antipolis, France. 

bergerOessi . f r 

Works around programming techniques aim at expressing higher and higher level 
of abstraction I49I56I8I . and, at the same time, giving more and more controls on 
language mechanisms 1141251711 . The Aspect-Oriented Programming (AOP) [3^ 
contributes to this evolution. It makes it possible, through transverse languages, 
such as D framework HU or AspectJ HU, to provide a clear separation of con- 
cerns between global properties cross-cutting the language mechanisms and the 
language mechanisms themselves. 

However AOP is limited because for each aspect language must be defined a 
specific Aspect Weaver depending on the application target language. To increase 
the independence of the Aspect Weaver toward the application language, we 
need, when defining an aspect, to give a formal description of control locations 
(we call these locations join points) where the actions (i.e. content of aspect 
programs) must be executed at runtime in the application source code. Our 
solution for this formal description is the Join Point Aspect Language (JPAL). 

Moreover the potential of AOP is mainly studied to control the execution of 
systems in a static way. However current and future trends are the management 
of open systems that can be dynamically configured and adapt themselves to 
the execution environment |34] . Therefore, we argue that in such cases aspect 
programs should remain available at runtime to be modified or reconfigured in 
order to catch dynamic properties. The JPAL is a very good way to attain this 
object. 

This poster summaries our proposition about implementation of Aspect Weav- 
ers. It reports our works to abstract the implementation of aspect languages by 
describing control locations with the join point aspect. It underlines the prob- 
lem to dynamically manage modifications of aspect programs and describes our 
solution which provides flexibility to add, replace or configure aspect programs 
at runtime. 



5 Customization of Relationships between Types 

Adeline Capouillez, Robert Chignoli, Pierre Crescenzo, Philippe Lahire 
Laboratoire I3S (UNSA/CNRS), Team OCL, Sophia Antipolis, France. 
{Adeline . Capouillez I Robert . Chignoli I Pierre . Crescenzo I 
Philippe . Lahire}@unice . f r 

The problematics of our study is set in the framework of object oriented lan- 
guages providing notions of class and inheritance, especially in the perspective 
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of GL. In these languages, such as Java [Ij, C++ [B8] and Eiffel |^, it is fre- 
quent to use the provided inheritance mechanism in order to implement different 
kinds of relationships. For instance, people use inheritance to implement a strict 
sub-typing as well as a basic source code reuse operation [51] . This range in the 
use of inheritance demonstrates the very wide interest of this mechanism but 
also shows a straightforward default. It is very difficult for a programmer to 
specify what is the use he wishes to make of this mechanism, including all the 
consequences that it may imply according to control, readability, documentation, 
maintainability and evolution of programs. 

Thus, our goal is to generalize and control the relationships between types, 
such as inheritance and client link. We also want to offer the ability to specify 
new relationships like generalization, code reuse, versioning, . . . For that, we 
have defined a model, called OFL PE], dedicated to the customization of re- 
lationships {hyper- genericity Pj) between types in Object oriented languages 
junsi. The three main entities of this model are: relationship, description and 
language. We want to improve the system expressiveness by providing parameters 
which characterize the relationships. In order to describe relationship semantics, 
we will propose combinations of values for these parameters. Thus we will sup- 
ply traditional relationships such as inheritance, client link or specialization and 
others, more original, such as generalization or code reuse. 

A concept-relation represents a kind of relationships between types. For in- 
stance, in Java, we have inheritance between classes (extends), inheritance 
between interfaces (extends), implementation between interfaces and a class 
(implements), ... A concept-description figures a sort of active container that we 
generally called class in object oriented languages. In Java, we can find classes, 
interfaces, arrays, inner classes, . . . Finally, a concept-langage describes the no- 
tion of programming language. It is mainly a composition of concepts-relations 
and concept-descriptions and a set of conditions to use them. 

Each of these three concepts includes a set of parameters (for example: car- 
dinality for the concept-relation). They also have available algorithms called 
actions (for instance: lookup searches the right feature during dynamic binding) 
and boolean functions called controls (for instance: is_argument_valid verifies 
if the effective argument is compatible with the formal one) which take value of 
parameters into account. If the use of parameters are inadequate, the program- 
mer can use meta-programming to change semantics of actions and controls. But 
this case must be exceptional. 

On posters, we want to present some elements of our concepts of relationship, 
description and language. Then, we shall give some parameters and actions to 
show examples. At last, we shall show how to add a relationship for code reuse 
in Java. 
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6 Communication Oriented Reflection 



Walter Cazzola 

DISCo - Department of Informatics, Systems, and Communication, 
University of Milano - Bicocca, Milano, Italy 
cazzolaOdisco . unimib . it 



The Problem 

A crucial issue of designing reflective systems consists in choosing a good meta- 
model in their application domains. Most of the meta-models that have been 
presented so far are object-based models. In these models, every object is as- 
sociated to a meta-object, which traps the messages sent to the object and 
implements the behavior of that invocation. 

These approaches are not appropriate to handle all the aspects of distributed 
computing. In particular adopting an object-based model to monitor distributed 
communications, the meta-programmer often has to duplicate the base-level 
communication graph into the meta-level augmenting the meta-program com- 
plexity. Thus, object-based approaches to reflection on communications move 
the well-known problem m of nonfunctional code intertwined to functional one 
from the base- to the meta-level. Simulating a base-level communication into the 
meta-level, as advocated in [49j , allows to perform meta-computations either re- 
lated sending or receiving action, but not related to the whole communication or 
which involve information owned both by the sender and by the receiver without 
dirty tricks. This trouble goes under the name of global view lacking. The global 
view concept is defined in m as the situation in which the meta-computation 
can involve all base-entities and aspects involved in the computation which it 
reifies and as advocated in , reflection inherits the trouble of the global view 
lacking from the object-oriented methodology which encapsulates the computa- 
tion orthogonally to the communication. 

Besides, object-based reflective models allow only to carry out global changes 
to the mechanisms responsible for message dispatching, neglecting the manage- 
ment of each single message. Hence they fail to differentiate the meta-behavior 
related to each single exchanged message. In order to apply a different meta- 
behavior to either each or group of exchanged messages the meta-programmer 
has to write the meta-program planning a specific meta-behavior for each kind 
of incoming message. Unfortunately, in this way the size of the meta-program 
grows to the detriment of its readability, and of its maintenance. 



Our Solution 

To render the impact of reflection on object-oriented distributed framework ef- 
fective, and to obtain a complete separation of concern, we need new models and 
frameworks especially designed for communication-oriented reflection, i.e., a sort 
of reflective middleware suitable for enriching, manipulating and replacing the 
distributed communications and their semantics. That is, we need to encapsulate 
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message exchanging into a single logical meta-object instead of scattering any 
relevant information related to it among several meta-objects and mimicking 
the real communication with one defined by the meta-programmer among such 
meta-objects as it is done using traditional approaches. 

To fulfill this commitment we designed a new model, called multi- channel 
reification model |13| . The multi-channel reification model is based on the idea of 
considering a method call as a message sent through a logical channel established 
among a set of objects requiring a service, and a set of objects providing such a 
service. This logical channel is reified into a logical object called multi-channel, 
which monitors message exchange and enriches the underlying communication 
semantics with new features used for the performed communication. Each multi- 
channel can be viewed as an interface established among the senders and the 
receivers of the messages. Each multi-channel is characterized by its behavior, 
termed kind, and the receivers, which it is connected to. 

multi-channel = (kind, receiver j, . . . , receiver^) 

Thanks to this multi-channel’s characterization it is possible to connect several 
multi-channels to the same group of objects. In such a case, each multi-channel 
will be characterized by a different kind and will filter different patterns of mes- 
sages. 

mChaRM [I2j is a framework developed by the authors. This framework sup- 
plies a development and run-time environment which support the multi-channel 
reification model. Multi-channels will be developed in JAVA, and the underly- 
ing mChaRM framework will dynamically realize the context switching and 
the causal connection link. A beta version of mChaRM, documentations and 
examples are available from: 

http : //www. disi .unige . it/person/CazzolaW/mChaRM_webpage .html 

7 Revisiting Separation of Concerns with an 
Aspect-Oriented Framework 

Constantinos A. Constantinides and Tzilla Elrad 
Department of Computer Science 
Illinois Institute of Technology. Chicago, IL. USA 
{conscon, elrad}® Charlie . cns . iit . edu 
WWW. iit . edu/~concur 

As the size of software systems increases, their design has reached a complexity 
that requires software engineers to revisit the principle of separation of concerns 
USEH!, which refers to the realization of system concepts as separate software 
units. This principle is essential to software development since its benefits in- 
clude better analysis and understanding of systems, easy adaptability, maintain- 
ability and high degree of reusability. Further advantages include the avoidance 
of inheritance anomalies [48| . Traditional software organization has been per- 
formed along some form of functional decomposition. Different paradigms and 
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languages support the implementation, and composition of subparts into whole 
systems through the availability of some modular unit of functionality, or com- 
ponent. The concept of component is well supported by existing programming 
technologies with a large collection of constructs, such as procedures and ob- 
jects. In essence, traditional software decomposition and current programming 
languages have been mutually supportive |35| . At the same time, separation of 
concerns can only be beneficial if the different concerns can be effectively com- 
posed to produce the overall system. In order to support separation of concerns 
the OOP paradigm seems to work well only if the problem to be solved can be 
described with relatively simple interfaces among objects. Unfortunately, this 
is not the case when we move from sequential programming to concurrent and 
distributed programming. The component interaction in complex system vio- 
lates simple object interfaces. As a result, the benefits associated with OOP 
no longer hold. One of the reasons is the inherent structure of today’s software 
systems that conceptually does not lead itself to be safely decomposed. As dis- 
tributed systems become larger, the interaction of their components is becoming 
inherently more complex. Component interactions limit reuse and make it diffi- 
cult to validate the design and correctness of software systems. Reengineering of 
these systems is needed in order to meet future changes in requirements. This 
component interaction is based on a number of properties that do not localize 
well in one modular unit, but tend to cut-across groups of components. Exam- 
ple properties include synchronization, scheduling, and fault tolerance. These 
are properties that affect the performance and semantics of the system. The 
term ” code-tangling” [35j is referred to as the phenomenon where the imple- 
mentations of such properties cut across groups of functional components. This 
code-tangling and the resulting high coupling of components destroys modular- 
ity, making the source code difficult to develop and difficult to understand. It 
also limits reuse, making the source code difficult to evolve. It further makes 
programs more error prone. In essence, it destroys the quality of the software. 
In |7] the authors refer to these phenomena as ’’composition anomalies”. This 
composition anomaly requires a shift in the methodologies used to separate con- 
cerns. In conjunction with modular composition, adaptability and reuse remain 
major issues to be considered while building complex software systems. These 
cross cutting properties have been termed aspects by pg and Aspect-Oriented 
Programming (AOP) is an emerging methodology that addresses components 
and aspects at the analysis and design phase of the software life-cycle, using 
mechanisms to compose them at the implementation level. Most of the architec- 
tures discussed in the literature follow a linguistic approach either in the form 
of an aspect language to support the definition of aspects m or by the sup- 
port of a reflective architecture where aspects can be defined as meta-objects 
m- Our work concentrates on concurrent programming and within this con- 
text, on the provision of synchronization and scheduling aspects in a concurrent 
software system. In order to build an aspect-oriented software architecture, we 
focus on a number of requirements such as separation of concerns throughout all 
phases of the software life cycle, adaptability and reuse. In peg we presented 
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our proposal for a framework solution to support the design of concurrent sys- 
tems. In the Aspect Moderator Framework a concurrent system is composed as 
a cluster of cooperating classes where components and aspects are defined by 
classes and they are designed relatively separately from each other. Access to a 
functional component is controlled by a proxy object, which also uses the factory 
method pattern to create aspect objects for each method (participating method) 
of the functional component that has to be associated with some aspects. Fur- 
ther, each aspect is implemented by a set of assertions, which are defined by an 
interface. Within the proxy object, each participating method is guarded by a 
pre-activation and post-activation phase. These phases are implemented in the 
aspect moderator object. The semantics of the system are defined by the aspect- 
component interaction, and the order of activation of aspects. Upon a message 
reception that involves a participating method, the proxy will delegate the re- 
sponsibility to the aspect moderator to evaluate the pre-activation phase. The 
moderator will, in turn, evaluate all required aspects (in some specified order) 
of the participating method by calling the precondition of all required aspects. 
Upon successful return of the pre-activation phase, the proxy will call the actual 
participating method. Once execution is complete, the proxy will initiate the 
post-activation phase, by delegating responsibility to the moderator to evaluate 
the post-activation on the given method. During this phase, the aspect moder- 
ator will call the post-condition of the required aspects (also in some specified 
order). The framework has been demonstrated by example implementations in 
the Java language EESEi, although the model manages to remain language- 
neutral. The framework has further been demonstrated to provide an adaptable 
model mB that allows for an open language where new aspects (specifications) 
can be added and their semantics can be delivered to the compiler through the 
aspect moderator object. Further, the model can address those aspects whose 
relationships with components are cleanly supported through the use of asser- 
tions. The framework provides a clean separation of concerns in both design and 
implementation. This separation allows for maximum reusability both in terms 
of components and aspects. 

8 Object Persistence: A Framework Based on Design 
Patterns 



Jorg Kienzle & Alexander Romanovsky 
Swiss Federal Institute of Technology Lausanne 
CH - 1015 Lausanne EPFL, Switzerland 
& Department of Computing Science, University of Newcastle 
NEl 7RU, Newcastle upon Tyne, United Kingdom 
Joerg . KienzleSepf 1 . ch, Alexander . RomanovskySnewcastle .ac.uk 

Introduction 

Research into persistent programming languages and systems in recent years has 
shown that this technology is useful for developing complex software in many 
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problem domains. Data persistence is required when values from a program exe- 
cution are used in a later execution. Software fault tolerance mechanisms based 
on backward error recovery use some sort of persistence to provide state restora- 
tion in case of computer crashes. Transaction durability is often implemented 
using persistence techniques. How the data is saved and what kind of storage 
medium is used for that purpose depends on the applications demands and can 
vary considerably from one application to another. Unfortunately, widely used 
object-oriented programming languages still do not offer support for persistence. 



The Framework 

The poster describes a framework for providing object persistence in object- 
oriented programming languages without modifying the run-time system or the 
language itself. The framework does not rely on any kind of special programming 
language features. It only uses basic object-oriented programming techniques, 
and is therefore implementable in any object-oriented programming language. 
The complete description of the framework can be found in [dbj . The framework 
clearly separates persistence control from storage control. Choice of the stor- 
age to be used for saving application data depends heavily on the application 
requirements. The characteristics such as performance, capacity of the storage 
media and particularities of usage may affect the choice. This is why a hierarchy 
of different storage classes, useful in different application domains, is introduced 
(see figure [ID . 

The storage hierarchy is split into volatile storage and non-volatile storage. 
Data stored in volatile storage do not survive program termination. An exam- 
ple of a volatile storage is conventional computer memory. Once an application 
terminates, its memory is usually freed by the operating system, and there- 
fore any data still remaining in it is lost. Data stored in non-volatile storage 
on the other hand remains on the storage device even when a program termi- 
nates. Databases, disk storage, or even remote memory are common examples of 
non-volatile storage. Since the data are not lost when the program terminates, 
additional housekeeping operations are needed to establish connections between 
the object and the actual storage device, to cut off existing connections, and 
to delete data that are not used anymore. These operations are Open, Close 
and Delete. Persistence can be implemented in a stronger form to support fault 
tolerance mechanisms which deal with faults of different types, including soft- 
ware design faults, hard-ware crashes, and transient faults of the underlaying 
software. 

Among the different non-volatile storage devices, we distinguish stable and 
non-stable devices. Data written to non-stable storage may get corrupted, if the 
system fails in some way, for instance by crashing during the write operation. 
Stable storage ensures that stored data will never be corrupted, even in the 
presence of application crashes and other failures. 

The framework is to be used by two different types of programmers: persis- 
tence support Programmers and application programmers. Persistence support 
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Fig. 1. The Storage Hierarchy 



programmers add support for new storage devices to the framework by extend- 
ing the storage class hierarchy. Application programmers use the framework to 
declare persistent objects. When instantiating a new persistent object, the ap- 
plication programmer specifies where the state of the object will be saved by 
choosing among the existing implementation of storage devices. The operations 
defined for persistent objects allow the application programmer to save or re- 
store the state of the object at any time. The structure of the framework is 
based on wellknown design patterns (Strategy, Factory Method and Serializer). 
The advantages of using design patterns and object-orientation in this context 
are substantial. In particular, they allowed us to achieve the following important 
goals: 

— Clear separation of concerns: The persistent object does not know about 
storage devices or about the data format that is used when writing the state 
of the object onto the storage device and vice versa. 

— Modularity and extensibility: It is straightforward to define new persistent 
objects or add support for new storage devices. 

— Safe and flexible storage management: Storage leaks leading to wasted space 
on the storage device have been prevented. Switching storage devices is 
straightforward. 

An implementation using the object-oriented programming language Ada 95 
has been developed m- The following storages have been implemented: main 
memory storage, file storage, remote storage, mirrored storage and replicated 
storage. 
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9 Cranium: Reducing the Abstraction Penalty with 
Specifications 



Sean McDirmid 
University of Utah, USA 
mcdirmidOcs . Utah . edu 

Abstraction is an essential tool for building large software systems. The use of 
abstraction, however, sacrifices performance for software engineering benefits. 
The purpose of compiler optimizations is to recover some of the performance 
lost by using abstraction. Unfortunately, compiler optimizations are limited by 
the amount of information they can extract through analysis of the program’s 
implementation: implementation analysis is limited by the availability [ZD! and 
simplicity of implementations. 

Embedding specifications into a program allows aspects of the program to 
be reasoned about automatically. A design-by-contract language |D2] embeds 
preconditions, postconditions and invariants into the declaration of a virtual 
method. In Cranium, implementation analysis is augmented with the use of for- 
mally specified contracts to increase the effectiveness of compiler optimizations. 
Since a method can be satisfied by many different implementations, a contract is 
built around the notion of abstract state and abstract behavior SB- The abstract 
state of a program is independent of the concrete state of any class. Abstract 
behavior describes dependencies and updates to the abstract state of a program. 

Cranium specifications are used to reason about changes in the abstract state 
caused by a method call. The compiler can use this information to relax data 
dependencies and eliminate redundant method calls. For example, a segment of 
code that swaps two elements of a list can intuitively be written as follows: 
Object to = list.get(iO); Object tl = list.get(il); 
list.set(il, to); list.set(iO, tl); 

The method set’s behavior is specified to return the previous value of a get 
on the index being updated. The compiler knows this through a specification 
and can easily make the following optimization: 

Object to = list.get(iO); XXX: Object tl = list.get(il); 

Object t2 = list.set(il, tO); list.set(iO, t2); 

Prior work in design-by-contract languages has used contracts to check con- 
formance by compiling to assertions at runtime I33I38I52I21II . These contracts 
are written in a language adequate for execution, not static analysis. Cranium 
contracts are written in a restricted language suitable for static analysis rather 
than execution. 

Programmers already use the implied contract of a method to perform opti- 
mizations by hand. However, the ability to hand-optimize code correctly becomes 
harder as the method behavior and its interactions with other method behavior 
become more complicated. Deeply hand-optimized code tends to obscure the 
original straightforward meaning of the code, which makes evolution and main- 
tenance more difficult IZDj. Clearly, we do not want the programmer to do these 
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contract-based optimizations by hand. The programmer instead should concen- 
trate on making the program algorithmically efhcient; the compiler should be 
responsible for contract-based optimizations. 

We are designing and implementing the Cranium contract language, which 
can be used to specify the behavior of classes written in Java. A bytecode- 
to-bytecode Java compiler then uses these contracts to perform optimizations. 
The resulting bytecode can be executed under a standard virtual machine that 
executes Java bytecode. As a result, Cranium contracts can be easily integrated 
into existing runtimes and applications. 



10 Jiazzi: A Java Component System 

Sean McDirmid, Wilson Hsieh, Mathew Flatt 
University of Utah, USA 
{mcdirmid, Wilson, mflatt}@cs .Utah. edu 

Software components support reuse in large software systems by enforcing bound- 
aries of separate development and distribution. Component abstractions, how- 
ever, are missing in many object-oriented languages. They instead rely on class 
systems augmented with component-like features, such as namespace manage- 
ment, information hiding, separate compilation and dynamic loading. Even when 
classes are augmented with component-like features, they make inadequate com- 
ponents. Classes are poor containers of other classes. Many meaningful designs in 
an object-oriented language contain many classes that interact closely together. 
The imports of a class are fixed statically and an instantiation of a class can 
only be parameterized at runtime. There is no mechanism in a class system to 
configure the imports of a class at link time. 

Jiazzi components contain, export and import classes. In the definition of a 
component, imports and exports are represented by a shape. A shape describes 
the visible methods and superclasses of a class in terms of other imported and 
exported classes. In knowing the shape of an import, the component can be 
compiled without knowing which classes will be imported into an instance of 
the component at link time. Only exported classes can be used outside of the 
component and only their shape is visible. 

Jiazzi components can be combined safely at link time with an expressive 
linking language. Components are linked by connecting an exported class from 
one component instance to the import of another component instance. Link-time 
type checking is performed to ensure that the exported classes shape is compati- 
ble with the imports shape. The imports of a component can be instantiated and 
sub-classed inside the implementation of the component. By allowing a class to 
subclass an import, Jiazzi supports mixin |24| constructions. Ambiguous meth- 
ods created by mixin construction are disambiguated in the linking language. 

Classes contained within the same Jiazzi component can view each others 
implementation details. If the shape of an import specifies that the import is a 
subclass of an export, then all visible implementation details of that export can 
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also be viewed in the import. By linking components cyclically, this inheritance 
structure can be used to customize an export outside of the component before 
connecting the customization back into the component through an import. Ad- 
ditional link-time checking ensures that cyclic linking does not cause inheritance 
cycles. 

With Jiazzi, reusable software components such as frameworks can be built 
without the required use of many design patterns |26| . A framework is a reusable 
design described by a system of classes that are specialized together as the 
framework is customized . Normally, patterns such as abstract factories and 
composition are used to ensure that only the final customizations of each class 
in the framework are instantiated and inherited. In Jiazzi, deferred imports with 
normal inheritance and instantiation can be used instead. 

Jiazzi components are defined and linked in a language that is completely 
separate from and requires no modifications to the current Java language. A 
stub generator uses the shape of an import to generate stubs for classes that will 
be imported when the component is linked. The component is linked with other 
components through a custom classloader. To enable dynamic loading and link- 
ing, components can be manipulated manually at runtime using programming 
interfaces added to the Java runtime. 

11 Interfaces with Skeletal Implementations in Java 

Markus Mohnen 

Lehrstuhl fiir Informatik II, RWTH Aachen, Germany 
mohnen@informatik.rwth- aachen . de 

Java’s interfaces allow the definition of class properties independently of class in- 
heritance. Since interfaces allow multiple inheritance, their potential for reusable 
code is higher than those of abstract classes. We present a technique for aug- 
menting interfaces with skeletal implementations by using Java’s inner classes. 
Using this technique, we propose an extension of Java for providing skeletal 
implementations in interfaces. 

Multiple inheritance of method implementations from more than one super- 
class in object oriented languages has been identified as a cause of problems for 
a long time (see for instance [66167] !. One of the main problems is that it seems 
impossible to define a satisfactory general strategy for choosing or combining 
inherited method implementations. 

Newer languages like AdaNF or Java mE\ avoid these problems by 
not allowing multiple inheritance of method implementations at all. In contrast 
to AdaNF, however, which does not support multiple inheritance as a language 
construct, Java allows multiple inheritance of signatures: Interfaces allow the 
definition of properties which can be implemented by classed Since interfaces 
can be used just like classes in declarations and signatures, it is possible to 

^ Interfaces are similar to what is called type classes in the functional language Haskell 

m- 
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base programs on properties of classes instead of classes. Furthermore, the in- 
heritance hierarchy of interfaces is independent of the class inheritance tree. 
Therfore, this language feature gives a higher potential to produce reusable code 
than abstract classes, i.e. classes where the implementation of some methods is 
omitted. The Java 2 API makes extensive use of interfaces. For instance, the 
package java. util contains six interfaces hierarchies. 

In many cases it would be useful to equip interfaces with skeletal implemen- 
tations of methods, which can be used by a class implementing the interface. 
Skeletal implementations are useful since they reduce the effort required to im- 
plement the interface. They are especially interesting if there is a canonical 
way to implement methods of the interface in terms of some other methods. 
In these cases, an implementation can be obtained by implementing the base 
methods and use skeletal implementations of the other methods. The usefulness 
of skeletal implementations has also been seen by the Java developers. In the 
Java 2 API there are abstract classes which provide skeletal implementations for 
some of the interfaces. For instance, the class java. util. AbstractCollection 
is an abstract class implementing j ava. util . Collection except for the meth- 
ods iterator and size. 

The approach of adding abstract classes containing skeletal implementations 
has drawbacks for the implementation of the interface and for the implementa- 
tion of the abstract classes: 

— To use the skeletal implementation of the interface, a class must extend the 
abstract class. Consequently, the programmer is no longer free to create an 
inheritance hierarchy matching the needs of the problem at hand. Altogether, 
this abolishes the advantages of interfaces over abstract classes. 

— To provide skeletal implementations for all interfaces in an interface hier- 
archy with multiple inheritance, it is unavoidable to duplicate code in the 
abstract classes. 

We suggest a different approach for providing skeletal implementations of 
interfaces. Java’s inner classes can be used to add default implementations to 
an interface without creating a separate abstract class. Using this approach, we 
avoid the problems mentioned in the last paragraph. Based on this technique, we 
propose an extension of Java, which allows to insert skeletal implementations 
directly in interfaces. 

12 An Architectural Pattern for Consistent Observations 
of Active Systems 

Gianluca Moro, Antonio Natali, and Mirko Viroli 
DEIS - University of Bologna 
via Rasi e Spinelli 176, 47023 Cesena (FC) Italy) 

{gmoro , anatali ,mviroli}@deis .unibo . it 

The most popular approach for system designing is still represented by the client- 
server paradigm, where a server offers a set of functionality (or services), which 
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allow elaboration, reading and the changing on its status; the server-side makes 
such services known to clients by publishing them through an application pro- 
gram interface (API or entry interface). What is emerging from current expe- 
rience with the engineering of complex software systems is that there are also 
activities which are mainly interested in observing a system rather than using it; 
monitoring or controlling activities are for instance typical tasks of observation. 
If observation tasks were implemented according to the client-server paradigm, 
observation clients could be designed as polling observers, continuously querying 
knowledge sources to verify possible state changes. This may cause two prob- 
lems: lack of effectiveness, as this approach does not guarantee the perception of 
all status changes over the time, in fact the system might change more rapidly 
with respect to the query frequency; lack of efficiency, as the system is forced 
to serve all the queries even when nothing has changed, thus wasting compu- 
tational resources. To overcome these problems observers can be more easily 
thought of as sorts of registered observers, which have to be notified when some- 
thing happens in the part of the world they are interested in. As a result, the 
general notion of an active system comes in as something made up of compo- 
nents or sets of components which are able to manifest any change to their state 
as an observable event. Correspondingly, we introduce the notion of observa- 
tion interface (01), which an active system could implement and publish, as in 
the case of its API, in order to make its evolution available to observers, and 
which observers could also use to register themselves in. The fundamental re- 
quirement for guaranteeing sound observations is to make only consistent states 
observable, independently from the number of concurrent clients or observers. 
Effective models and middleware-technologies such as Trans action Processing 
Monitors, DBMS Transaction Managers |2^ and Object Trans action Manager 
|54| can guarantee this requirement in a client-server scenario but not in an 
observation scenario. In fact these models and technologies do not take the ob- 
server actor into account because they supply an API but not an 01. Therefore, 
observers are forced to use API and work as polling clients to obtain consis- 
tent states of the system. In other words the 01 realizes a publish-subscribe 
protocol which, unlike current solutions (e.g. |22l l is transactional-aware. There 
are principally two ways to allow consistent observations through notifications 
also: (i) by providing an 01 to systems encapsulating the tasks of events’ col- 
lection, manipulation and notification to observers; (ii) by adding appropriate 
models and solutions to the above mentioned technologies (TP, OTM, etc. ), in 
order to handle the consistent notification problem. Here we deal with the for- 
mer approach, which has the great advantage of also being applicable to legacy 
systems, as existing active databases and object frame works. The 01 performs 
a task which includes both different and heterogeneous sub tasks, each imple- 
mentable through the use of a wide range of policies, depending for instance 
on the application domain. For this reason we split this component into three, 
mostly independent parts, namely the Synchronizer, the Evaluator and the No- 
tifier. The Synchronizer accepts system events - i.e., the events directly fired by 
the observed system - and decides how to group them into wholes for further 



298 Mireille Blay-Fornarino and Anne-Marie Dery 



processing. This can be specified through two activities: (i) an event collection 
logic, which decides how to classify events, (ii) plus a firing logic, which decides 
when a group of system events is ready to be sent. The first activity can be 
implemented by including in each event the identifier of the transaction that 
generated the event. The second activity can be realized by waiting the system 
for notifying commit or rollback events. The Evaluator performs the mapping 
between system events into the events which will be notified to the observers, the 
output events. This task becomes necessary when the events fired by the system 
are of a lower abstraction level with respect to those in which the observers are 
interested in. This produces relevant output events which can be useful to sum- 
marize a system changes by hiding low-level details. The Notifier is responsible 
for communication with the observers. It performs two activities: (i) it stores 
the observers registrations and (ii) it notifies output events. Hence useful fea- 
tures can be considered: multiple registration detection, notification semantics 
related to system transactions, handling requests of single/multiple notifications 
and dealing with event dependencies (inclusion, inter section etc.). For space 
reasons we forward the interested reader to additional information references at 
the URL: http:/ /elena. ingce.unibo.it/observation/observation.html 

13 Redesigning Distributed Applications to Provide 
Co-operation 

Roose Philippe, Dalmau Marc, Aniorte Philippe 
Laboratoire d’Informatique Appliquee (LIA) 
lUT Informatique de Bayonne Chateau Neuf, Place Paul Bert, 

64100 Bayonne - France 

roose I dalmau I aniorteOiutbay .univ-pau. fr 

Increasingly, present day applications are composed of distributed modules (a 
production cell, an automata, a software component, etc.) interconnected with 
a network. While these modules function with a common goal, we cannot say 
however that they co-operate. They have of course not been conceived for this 
and they do not know necessarily how to synchronize with each other, nor how 
to exchange information. Nor do they know how to constitute themselves in 
workgroups (as a set of modules with a common goal composing of one compo- 
nent). Our work is based on previous work done on Active DataBases (ADB) 
m- Active DBMS are able to recognize specific situations and to manage them 
without explicit requests from the user or the application which is similar to 
what happens in the cooperative work domain [2]. They are mainly based on 
EGA (Event-Condition- Action) rules. We have already proposed to extend these 
mechanisms to include the cooperation and the distribution in m- Teams work- 
ing on the domain of ADB quickly realized the need for specific methods adapted 
to this kind of management. Generally, we are able to establish communications 
between them by using external operators (human operators or specifically de- 
signed machines like automatas), but it is almost impossible to have a workgroup 
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organization able to evolve dynamically in time, integrating new modules or ex- 
cluding others. Our contribution consists in proposing a method inspired by the 
previous ones and tools |65] allowing the migration of such applications into 
dynamic systems where operating modules are grouped into workgroups, and 
where the co-operation is established by connecting these modules to rules. So, 
we consider two abstract levels : the workgroup and the operative module, and 
we base the co-operation on the building of workgroups and on communication : 
communication with events and messages and communication with data sharing. 
In our method, we firstly define the workgroups according to the needs of the 
application, make the inventory of existing modules and look for the workgroups 
into which they can incorporate. Then, at the two abstract levels (workgroup 
and module), we itemize each kind of information which may be used for co- 
operation. We call this information elements of co-operation and we distinguish 
events for real-time communication, messages for communication with an en- 
capsulated semantic and data for persistent information sharing. Then, we try 
to directly link output information produced by workgroups and modules with 
input information needed by other ones. Not all of the needed information will 
be so supplied. To do that, we propose solutions based on rules used to create 
missing elements of co-operation by composition of other existing elements of 
co-operation. This composition of basic elements of co-operation is used to pro- 
duce other ones with a greater semantics needed by modules or groups. Rules 
will also be used to manage the dynamic of workgroups. That means modules 
will be included in or excluded from workgroups by the rule which manages this 
group. When included into one workgroup, it will receive all information des- 
tined to this group. Because we want our method to be operational, we propose 
to use a set of tools based on the well known concept of EGA (Event-Condition- 
Action) rules, inherited from the Active DataBase (ADB) domain, but extended 
to co-operative and distributed applications. The link between the method and 
the co-operative architecture (ELKAR) is made with a specification language. 
ELKAR capture elements of co-operation produced by modules circulates them, 
creates missing elements and manages dynamic of workgroups. It’s based on a 
set of rules defined by an associated method. 

14 RoleJ: A Role-Based Java Extension 

Andrea Savigni 

(D.I.S.Co. - Universita di Milano-Bicocca. Milan, Italy) 
savigniOdisco . unimib . it 

RoleJ is a Java extension that includes the concept of role as a native one. RoleJ 
also provides for the definition of restricted- visibility methods i.e., methods that 
are only visible to certain roles. 

Introduction 

In current object-oriented languages the means for expressing method visibility 
are extremely limited. In most such languages, a method can essentially be either 
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public or privat^H Since the interface of a class must clearly be public (and thus 
open to anyone), there is no quick way to know which other parts of the system 
use it. Thus, modifying an interface after its deployment (which unfortunately 
is sometimes necessary) can lead to disastrous results. If one could limit the 
visibility of methods, the impact of an interface change would be greatly reduced. 

RoleJ is a Java extension that addresses this problem. RoleJ is based on the 
two fundamental concepts of selective method export, whereby a software engi- 
neer, when designing the interface of a class, can freely decide who is allowed to 
call a method and who is not, and roles, which specify the entities that methods 
are exported to. RoleJ is work in progress; however, everything described here 
has been fully implemented by the author using Open Java [6^ . 



The RoleJ Language 

RoleJ extends Java by defining one new keyword (playsRole) and one new 
modifier (restrictedTo). In order to realise such extension, three metaclasses 
were defined: Role, RolePlayer, and SelectiveExporter. 

A role is an empty class instantiating the Role metaclass. Roles closely resem- 
ble interfaces, but with a fundamental difference: whereas an interface declares 
what you can do to a class implementing it (i.e., a behaviour), a role defines 
what a class playing that role can do to the rest of the world (i.e., a capability). 
More practically, a role defines which methods a class playing that role can call. 

A role player in RoleJ is a class that instantiates the RolePlayer meta- 
class and plays one or more roles. This is accomplished via the newly-defined 
playsRole keyword. For a class to be able to play a role, the latter must have 
already been defined (as a class instantiating Role), and the corresponding file 
must have already been compiled. This is the expression of a fundamental design 
principle (see Rule S] below) . Note that a class can play an arbitrary number of 
roles. 

RoleJ automatically enforces the following two rules set forth in namely: 



Rule 1 //i?2 is a subrole of R\ and C plays role R2, then C also plays role R\ 

Rule 2 If C2 is a subclass of C\ and C\ plays role R, then C2 also plays role R 

The fundamental feature of RoleJ is the possibility of exporting methods 
selectively. By using the restrictedTo keyword, a public or package method 
can be restricted to one or more roles only. The fundamental principle about 
restricted method visibility is expressed in the following: 

Rule 3 Methods are always exported to roles. Never are they exported to object 
classes. 

^ The need for a more flexible approach is apparent from the existence of protected 
and (in Java) package visibility. 
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RoleJ strictly enforces this rule: whenever a method has restricted visibility 
towards a role, the latter is checked for existence. In case of failure, a fatal error 
is issued and the compilation process ends immediately. We regard this rule as 
a fundamental one, in that exporting methods directly to object classes, as in 
Eiffel 1^, would seriously hinder reuse, because it would hard-code inside the 
class the dependency to a particular context. 

An object can call a restricted method if and only if that method is exported 
to a role played by the object’s class. Clearly, this only makes sense if roles have 
already been defined. Fortunately, this is just a side effect of a more general rule, 
that was inspired by m- 

Rule 4 In any 00 project, roles should be defined before classes. 

Finally, thanks to constructors, this mechanism also applies to object creation. 
If a class restricts a constructor visibility to a certain role only, then only classes 
playing that role can instantiate that object. 

Apart from helping in code maintenance, restricted visibility also has an 
obvious safety advantage, in that a designer can restrict critical operations (such 
as creation) to privileged roles. This way, only instances of classes playing those 
roles will be allowed to perform those critical operations. 

15 Typehole Model for Objects with Roles in Object 
Oriented Systems 

K. Chandra Sekharaiah, D.Janaki Ram & A.V.S.K.Kumar 
(Distributed & Object Systems Lab 
Department of Computer Science & Engineering 
Indian Institute of Technology Madras 
Chennai - 600 036, India) 

{hand, janaki , venkat}@lotus . iitm. ernet . in 

An object role model has to satisfy certain important characteristics such as vis- 
ibility, dependency, identity, multiplicity, dynamicity, and abstractivity. There 
are many problems in relation to these characteristics if traditional object ori- 
ented techniques such as specialization, aggregation and association are used for 
modeling objects with roles m- Concepts such as aspects and role hierarchies 
were proposed to extend the object oriented systems to support the modeling of 
objects with roles Existing role models do not provide effective message 

interpretation mechanism. The semantics of the method look up in these mod- 
els is based on the notion of delegation 128111571421 . The use of delegation for 
method lookup often gives rise to two problems. One problem is that it often 
leads to security problems at ancestor roles/root object. Another problem with 
delegation is that it leads to misinterpretation of messages. 

The authors propose Typehole model m for objects with roles. This satisfies 
all characteristic features of roles. In this model, a class called root class abstracts 
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two kinds of behaviors. Firstly, it abstracts time-invariant, role-independent be- 
havior called root behavior. Secondly, it abstracts time-variant, role-specific be- 
haviors of the root object by providing Typeholes. Formally, Typehole is “a set 
of declarations for attributes and methods that are specific to a role or sub-role” . 
It is declared in root class to defer the definition of a role-specific or subrole- 
specific behavior. Typehole definition is given in a separate class called glue class. 
Different glue classes provide different type definitions for a Typehole. Thus, the 
role-playing objects modeled after the Typehole model have the capability to 
take on different behaviors for any particular role. Role type can have different 
implementations [J. The Typehole concept facilitates such separation between 
role type and role implementation. In the Typehole model, messages are sent to 
particular, destination roles directly. The two problems at ancestor roles/root 
object that arise due to delegation do not arise in the Typehole model. 

A message filter is a dynamically pluggable object at the destination of mes- 
sages and provides the separation between message processing and message con- 
trol ISOj. It has the ability given by server (i.e. filter-client) object to intercept, 
manipulate and forward or bounce the messages sent to (and from) the server 
object. Such intermediate message manipulations are useful to address security 
concerns. Typehole model uses filtered delivery model of message processing for 
securing objects with roles. A filter-client class abstracts a role. Its filter class 
abstracts a security policy for that role. The model supports group filtering, 
allowing multiple filter-clients to be served by a single filter. 

Role interface and security filter interface are one and the same and is cap- 
tured as a Typehole in the root class. A glue class gives either a role definition 
or a security message filter definition for a role. Multiple glue classes capture 
multiple role definitions and security definitions for a particular Typehole to fa- 
cilitate role customization and security policy customization dynamically. This 
is called as role customization or role polymorphism. Researchers on role mod- 
eling have dealt with adding roles and deleting roles as part of role dynamics. 
But, the Typehole model has the additional capability to capture role polymor- 
phism as part of role dynamics. The operational semantics for role dynamics and 
role operations are supported in this model. This model is implemented in Java 
language. 

16 CyberChair: An Online Paper Submission 
and Reviewing System 

Richard van de Stadt 

Department of Computer Science, University of Twente, 

P.O. Box 217, NL-7500 AE Enschede, The Netherlands 
stadtScs . utwente . nl 

For the fourth time in succession, the Program Committee of ECOOP used Cy- 
berChair for the online submission and reviewing of papers that were submitted 
for the technical paper session. This paper gives a short overview of CyberChair. 
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Nowadays it is common practise to use electronic submissions for conferences, 
workshops and journals. Usually, people are allowed to send their submission by 
email. Although, compared to hardcopies, this is a big step forward, it may 
still be quite cumbersome to maintain the administration. Moreover, collecting, 
maintaining and comparing reviews by the program committee chair may also 
become quite tedious, if not troublesome, due to the large amount of material. 
CyberChair was first developed for ECOOP’97, and has been extended since, 
based on new ideas and the suggestions and remarks of its users (the chairs, the 
reviewers and submitters). 

In his paper Identify the Champion, Oscar Nierstrasz describes review pro- 
cesses in terms of a pattern language. CyberChair supports the following patterns 
in its implementation: Experts Review Papers, Champions Review Papers, Make 
Champions Explicit, Identify the Conflicts and Identify Missing Champions. 

CyberChair fully supports all activities that come with the review process: 
the abstract and (camera-ready) paper submission, the reviewer assignment 
(based on the reviewers’ preferences and expertise), the review submission pro- 
cess, the notifications of acceptance and rejection, the preparation of the pro- 
ceedings (according to Springer-Verlag’s procedure). Figure 1 shows an overview 
of the activities CyberChair supports or carries out. 
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After the abstracts have been submitted, the reviewers can indicate which 
papers they would like to review. This is done by providing several overviews 
of the abstracts, categorized by the conference topics that the authors claim 
their papers cover. Then, CyberChair uses this information and the reviewers’ 
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expertise on the conference topics, to calculate a proposal for the assignment of 
the papers to the reviewers. When needed, the PC Chair can make changes to 
the paper assignment. 

Each reviewer gets access to a personal password-protected webpage, from 
which he or she can download papers and submit reviews. Reviews can either be 
submitted online or via email. After submission of a review, CyberChair com- 
pares it with other reviews and displays the level of agreement of the reviewers, 
using a coloring scheme. The agreement level is shown at the top of the page 
and is asynchronously updated at regular intervals, so that the reviewers have 
up-to-date information about the agreement level of all papers assigned to them. 
CyberChair offers easy means of communication to resolve review conflicts. 

For the PC Chair, several overviews are available to monitor the review 
process. This allows for optimal preparation of the PC meeting. Papers are 
categorized using the classification (score) given by the reviewers, which makes 
it easy to distinguish between papers that have a fair chance of being accepted 
and those that are likely to be rejected. Further, papers with conflicting reviews 
can easily be identified. After the decision has been made about which papers 
have been accepted, CyberChair sends the notifications, with the comments of 
the reviewers attached, to the authors. 

After the submission of the camera-ready papers, CyberChair generates the 
following parts of the proceedings: the list of PC members, the list of co-reviewers, 
the table of contents and the author index. Further, it prepares the papers, ac- 
cording to the regulations of Springer Verlag (the publisher of ECOOP’s pro- 
ceedings), for uploading the proceedings to their ftp site. 
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